Re: STk_tc_instance and stklos.o

From: Erick Gallesio <>
Date: Tue, 16 Apr 1996 14:36:13 +0100

> Jonathan Berry writes
> I have an orgainizational request regarding STklos:
> The system I coordinate, LINK*, is written in C++ and embeds some STklos
> logic. It makes calls to STk_slot_set() and STk_slot_ref(), and uses the
> variable STk_tc_instance. When people port this, I want them to be able to
> link with libstk.a without worrying about stklos.o(so). David Fox pointed out
> that I can always redefine the functions under different names and use my
> own copies as long as stklos.h is included. I intend to do this, but I
> still have a problem with STk_tc_instance. Since it is defined in stklos.c,
> I currently need to link with stklos.o. It would be great if
> STk_tc_instance could be defined in a file whose object code ends up in
> libstk.a. If Erick feels that it's important to keep stklos.o(so)
> separate for dynamic loading, that's ok. Still, I am hopeful that the next
> release of STk will incorporate a solution to the problem of gracefully
> linking with code that uses STklos logic.

The STk foreign function interface was designed for allowing to create new
of objets, but also new types of functions. In this framework, I thought that
a complex function mechanism (such as STklos generic functions) was a good
candidate and that if the FFI could implement STklos generic functions, it
could implement nearly everything.

Since I'm touching STklos now (for embedding a cache), I can change things.
Having STklos in libstk.a provide several advantages:
        - gf would be faster, since the extended mechanism used with dynamic
          loading is not too efficient
        - gf could (at least more easily) be tail recursive.

I can see three ways to make STklos static:
        - the simpler way consists to hardcode it in STk (but #ifdef'ed with
          USE_STKLOS to allow it's exclusion if needed).
          Advantages: simpler to install
                      STklos will be in libstk.a
          Inconvenient: make the interpreter bigger (~ 25 on SunOs, probably
                         less on Linux)
        - use two compilation option such as USE_STKLOS and STATIC_STKLOS
          to have both both possibility
             STATIC_STKLOS defined: as the previous solution
              " " " undefined: complete dynamic loading as previuos
          Advantages: . STklos can be in libstk.a if needed
                      . the interpreter size will be the same for people which
don't need STklos
          Inconvenient: . make the installation harder (and I need someone to
                             explain those subtilities in the STk README file ;)
                        . Semantic difference between static gf and dynamic
                          ones since they static gf would be tail recursive
                          whereas synamic would not

        - use a mix of the two previous methods: Include support in the core
interpreter for generic functions and use dynamic loading for the rest.
          Advantage: . minimize the interpreter size growing
                     . don't complicate too much the interpreter installation
          Inconvenient: . what must be in libstk.a and what must be out?
                        . I'm afraid that we will arrive to solution 1 by transfering things
from to libstak.a soon.

What is the opinion of the mailing list?
The first solution is the simpler for me to implement, but it will augment a
little bit the interpreter size but isit really a problem?

                -- Erick
Received on Tue Apr 16 1996 - 14:37:38 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST