Re: STk_tc_instance and stklos.o

From: Erick Gallesio <eg_at_kaolin.unice.fr>
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
type
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
releases.
          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
                        process.
          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 stklos.so 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