[Gcl-devel] Re: "Fasload"

[Camm Maguire]

Greetings!

Peter Van Eynde <address@hidden> writes:

> On Mon, Dec 31, 2001 at 01:17:56PM -0500, Camm Maguire wrote:
> > Greetings, and thanks for your very helpful reply!
> > 
> > Do I have you permission to forward this to the gcl-devel list?
> > Others there I'm sure would be interested.
> 
> Of course.
> 

Thanks!

> > > Beware of gc problems. gc-ing code normally is expected of a lisp
> > > system :-(.
> > > 
> > 
> > I also find this gc stuff to be of dubious benefit, and certain
> > headache!  Why do people want it?  Would it be impossible to design
> > around malloc/free?
> 
> Impossible. Common Lisp just assumes that memory will be freed by the
> system. I would advise you to use the Boehm GC. It is well supported,
> easy to integrate and to use and people are even working on a MP
> version.
> 
> If you are confused about the need for GC in Lisp I could try to provide
> a few examples of the trickiness to expect.
> 

OK, I'll take your word on it.  At your suggestion, I'm also going to
take a crack at building gcl with libgc soon.  It does indeed look
simple to port, at least in rudimentary fashion.

> > > The 'best' option IMHO would be to compile the code with gcc, and then
> > > using just the code generated by gcc. Loading it directly into the
> > > lisp image as a code-vector and using the boehm conservative gc to
> > > manage the code and variables.
> > 
> > Thanks for the pointer to the gc!  I'd love to externalize this
> > piece.  It has limited portability too, but currently better than
> > gcl's.  I've read the pros/cons on their site, and they don't sound
> > too convincing!
> 
> The pro-cons is conservative GC with respect to a 'normal' Gc, correct?
> To be brutal: without type tagging of all objects this is the only way
> to go, and if you compile to/via C it quickly becomes the only realistic
> way. CMUCL uses a conservative GC for some time now (it is based on an
> older version of the Boehm gc, IIRC) so I do have some experience. The
> only bad thing we had was that some piece of pathological code would
> trick the GC into keeping all the memory 'alive'. A workaround has been
> found the the code-generation, but actually this problem has not happened
> in real life yet, and the solution does cost a bit of raw speed, so
> nobody seems to want to activate it :-).
> 

OK, again I'll take your word on it, especially since the first
experiment seem somewhat easy to try!

> > One question, could you elaborate a bit on what a lisp 'code-vector'
> > is?  My current crude understanding is that it is a memory map of a
> 
> A code vector is more or less ACL lingo for the code of a function. In
> ACL multiple function might share the same code. For instance:
> 
> (defun foo (x)
>  (sub-foo (1+ x)))
> 
> and
> 
> (defun bar (x)
>   (sub-bar (1+ x)))
> 
> have the same code. The difference in the function to call is stored in
> the 'data vector' of the difference functions. So foo and bar are the
> same code, but called with a difference data-vector to get the
> jump-address from.
> 

So the .text sections are the same, and all differences are in .data,
if I understand correctly?

> > linked set of lisp objects.  I'm trying to think of a way that I could
> > store it in a static local variable initialisation line.  Right now,
> > it is just appended to the end of the elf object file!
> 
> It is a pretty primitive way to load code at runtime I fear...
> 

Indeed.  I have been doing some work on gcl fasloading, and I think I
understand it now at least in rough form.  Basically, a relocatable .o
file has its .text and .data sections loaded into ram at an
appropriate place in gcl memory, the undefined symbols in the (elf) symbol
table are set to their values in the running program, and all
relocations are performed *keeping them relative* to the section
start.  ld would wipe the relocations, and put in absolute
references.  I think gcl has to do it this way, as it will then jump
to the initialization piece of the new code, and the whole stack will
then refer to the new image.  So loading at 0x40000000 for example and
trying to refer to 0x800000 will look something like an address of
0xc0800000.  Needless to say, one needs to pay attention on 64 bit
machines! 

> > > Oh, gcl has a pretty bad reputation when it comes to
> > > ansi-standardness. comp.lang.lisp just seems to prefer to 'convert'
> > > people to clisp/cmucl/sbcl instead of explaining why gcl just doesn't
> > > work as expected. In the clocc project on sourceforge there is the
> > > ansi-testsuite that might help you.
> > > 
> > 
> > Thanks for the pointer!  I'd really love to find a 'top ten' list of
> > desired ansi features for gcl in order of priority somewhere.  We have
> > a few experienced lisp coders joining the project now, and I'm
> > hoping they will be able to help here.
> 
> Hmm. Better ask that on comp.lang.lisp and prepare for a flame-war. I
> would say: packages, loop, exceptions, adding CLOS/PCL to the base
> system, type system.
> 

Thanks very much for this list and suggestion.  Will don my asbestos
and return to comp.lang.lisp hopefully sometime soon :-).

Take care,

> But I must admit that I've forgotten most of the gcl problems :-(.
> 
> Groetjes, Peter
> 
> -- 
> It's logic Jim, but not as we know it. | address@hidden
> "God, root, what is difference?" - Pitr|
> "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah