Misc ideas & comments

Matthias Hoelzl tc tc@gauss.muc.de
01 Apr 1998 00:00:50 +0200

strandh@cs.utexas.edu writes:

> > 2) The implementation of the stack handling needed to have efficient
> > first class continuations seems very difficult to integrate with the
> > gcc back end.  The possibilities that I see right now are a
> > setjmp/longjmp based stack copying approach, suitable only to use
> > continuations for error handling; or managing your own runtime stack,
> > which would somewhat defeat the aim of using the gcc back end.  The
> > cleanest approach would probably be to define some additional tree
> > codes with corresponding implementation in the gcc back end.  However
> > this would be a largish undertaking, and since I'm no proficient
> > C-hacker I don't think that I can handle this without a lot of support
> > from people more familiar with both C and the gcc back end.
> How about using a stack cache and migrating the stack frames to the
> heap whenever the cache overflows.  You get the advantage of using the
> normal stack convention of GCC but call/cc only involves flushing the
> cache. 

I was thinking about Hieb/Dybvig/Bruggeman's implementation of stacks
and the thought of using a stack cache simply didn't cross my mind
when I wrote the above paragraph.  But you are right, I should take
them into account.

> > I think that calling C from Scheme would not be a problem, 
> Right, you just tell the Scheme compiler to generate C compatible
> code. 
> > but that it
> > would be necessary to create stubs for Scheme functions that can be
> > called from C because you cannot simply stack-allocate all parameters
> > to a Scheme function.  
> I don't see why you could not simply stack allocate all parameters to
> a Scheme function.

Well, I was being unclear.  I could stack allocate all parameters, but
I want to have some flexibility for Scheme->Scheme calls, so that
e.g., the caller can heap-allocate escaping parameters and simply pass
a pointer instead of pushing them on the stack and having the callee
save them on the heap.  The compiler can create a module description
file (similar to Dylan) where the calling conventions are recorded for
other Scheme modules, but for the C compiler I need to provide a stub
function that takes the arguments as described in the function
definition.  (Another reason why C->Scheme calls probably need stubs
is that otherwise the C-caller has to take care of converting the
types to boxed/tagged format.)