This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Elk/Guile (Re: Bad news from the module/environment front)


On Wed, Jul 07, 1999 at 05:05:47PM +1000, Chris Bitmead wrote:
>  
> > > As much as I understand Guile is based on SCM.  Is that 
> > > correct? Are there special reasons for not having based 
> > > it on Elk which seems to have precisely the same goals 
> > > as Guile?
> 
> One would hope that if/when the guile C level interface stabilises
> somewhat, other schemes might take on board the guile interface and you
> would be easily able to port guile stuff to other Schemes. The most
> important part of guile is that everything has been ported to it.

Yes, the interface is probably one of the most important things
about guile. Unfortunately, it is most often the interface that
changes between other schemes (even when the overall language
behaviour is similar).

So I have gone over elk a bit more, and can provide some comparisons
to guile:

* Anything I said earlier about elk and C++ is totally wrong,
  the guts of elk is written in K&R C, very old style, does not even
  use `void', the C++ stuff seems added later as a compatability thing.
  A very plain C compiler would be enough to get the kernel going
  (same as guile & scm).

* Elk is less memory efficient than guile in its data storage,
  the elk equivalent to SCM is called Object and is a structure of
  one long and one int (i.e. 64 bits on most systems). Cells are
  two of these, strings, symbols and vectors are one Object plus one
  int length plus the actual data. elk seems to avoid most of the
  data packing machinations that guile inherited from scm. The result
  is cleaner code that is easier to read but probably double the
  memory requirements. I'm not sure how this affects speed because
  elk does less operations but has twice as much data to transfer
  around in function calls, etc.

  From the history notes, elk used to use a single long but changed
  to a struct at some point, obviously the memory wastage was considered
  a good trade-off for some extra benefit.

* The struct that elk uses does provide compiler protection against
  incidental type mismatching (guile suffers from SCM changing to
  int if the programmer is not paying attention). Obviously this only
  relates to extension code written in C.

* Elk requires explicit linking of garbage collectable C locals into
  the gc lists (similar to emacs) thus garbage collector does no
  conservative stack scan -- totally different to guile.

* continuations do a full copy of the stack and copy it back when
  the continuation is called -- same as guile.

* I can't find any thread support in elk, maybe I don't know what
  to look for but I think there is none.

* elk doesn't support complex numbers, guile does.

* elk doesn't support rationals, nor does guile. Both could probably
  do so with enough additional scheme code.

* elk does support bignums, so does guile.

* interface for primitives written in C that have a variable number
  of arguments is handled in an argc, argv style manner while guile
  uses a list (closer to scheme style). It seems that the low-levels
  of guile and scm are closer to C written in scheme style while elk
  uses C written like C. Probably guile is more efficient here...

* elk does not use a snarfer to scan the source code, the kernel has
  a large list of primitives in one big file and the modules use
  
    Define_Symbol()
    Define_Primitive()

  This is a minor difference really.

* elk has the option of a generational gc or a traditional mark&sweep
  (compile time option). The generational gc can either use memprotect
  and SIGSEGV or not but I'm not sure of the differences. In linux it
  took me a while to figure out how to scrape the address reference
  out of the signal handler, I should probably post this somewhere because
  the mechanism isn't documented (and it seems to change between kernel
  version 2.0 and 2.2).

* elk has a lot of native X11 code in its modules, I wish I could
  comment but I still can't get dynamic linking to work. elk has heaps
  of different ways to dynamic link and supports more than just Sun
  and ELF but the mechanism is really complex. From what I can see,
  on Linux-elf it stores ordinary object files (not .so files) in its
  library, then does a system() call to ld at runtime in order to
  change a particular object into a shared object, then uses dlopen
  to link with it, finally it reopens the shared object using libelf
  utilities and scans out the symbols, tyring to extract them and
  ignoring anything that can't be found.

* elk uses a require/provide style of module tagging, not a full
  module system. This system has a load-path and searches for both
  xxx and xxx.o depending on whether the module is compiled or not.


...and that's as far as I have gotten with it. Haven't done any speed
comparisons, probably won't do either. What I really want to do is
have a good look through the X11 code and figure out what is interesting
in there <shrug> when I get the linker to work.

	- Tel

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]