guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: broken GC


From: Maciej Stachowiak
Subject: Re: broken GC
Date: Fri, 5 Oct 2001 16:11:26 -0700
User-agent: Mutt/1.2.5i

On 05Oct2001 05:06PM (-0500), Rob Browning wrote:
> address@hidden (Thomas Bushnell, BSG) writes:
> 
> > It matters a great deal about what the rules are, not just that they
> > are well documented.
> >
> > Emacs has perfectly clear rules for this, but it has proven to be
> > *very* difficult to get C code correct in marking local variables for
> > the garbage collector, and is a persistent source of very hard to
> > track bugs.
> 
> Fair enough.  Since I posted that, I've heard enough about the Emacs
> issues to suspect that for a precise GC to be a *really* viable
> contender, some sort of code preprocessor would be a big help, but
> then you would have to contend with all the problems associated with
> maintaining something that can fully parse C code (whatever that
> means).
> 
> This seems somewhat risky.  I'm worried that we could end up in
> situations where our preprocessor expands a given source file
> differently than the eventual target C compiler (gcc, the sparc
> compiler, IBM's compiler, etc.), perhaps generating code that's
> incompatible with non-guile-preprocessed code living in the same app,
> or in other libraries on the system.
> 
> Imagine the case where a library uses "#" magic in it's header files
> to select the size and layout of data structures.  If we don't handle
> those "#" directives exactly the way that the target compiler will,
> then we could be in trouble.  I suppose one solution might be to
> require that any guile code has to be run through the preprocessor of
> the target compiler first, before being handed to the GC preprocessor,
> but is that really viable?
> 

I don't think you need to fully parse C to come up with a viable
preprocessor. Consider the current snarfing setup, for instance - it's
pretty dumb. The minimal requirements for an exact preprocessor would
be something like:

* Look for all declarations of SCM variables
* In the same block, but after the declarations, add the appropriate protect 
call
* At the end of the block, add the appropriate unprotect call (or else
make protection work in such a way that it ends automatically when the
variable goes out of scope).


Yes, C has a convoluted syntax compared to Scheme, but this is a
fairly simple source-to-source transform. And it should indeed be
possible to do the preprocessing first if necessary (most compilers
have a preprocess only flag which should result in the same #defines
being set as during compilation).

 - Maciej




reply via email to

[Prev in Thread] Current Thread [Next in Thread]