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.)
Matthias