On Wed, Feb 4, 2009 at 7:31 PM, Sam Rushing <[email protected]> wrote: > > Ok, now to my issue with the C stack. Am I correct in thinking that > BitC generates separate C functions and uses the C calling convention? > As I said in my other post to LtU, I want to avoid the big disconnect > between the high-level and low-level languages. My plan is to implement > call/cc in the low-level language and use it in both levels. > > Things I'd like to have in both languages: > > ...continuations...
First, let me say that I don't think you want continuations in their general form. There is no use-case for re-entrant continuations. Evidence collected from Scheme programs shows that >99% of all continuations are used at most once and (if called) are invoked before their defining scope exits. Basically, continuations are being used as an exception handling mechanism. The problem with re-callable continuations is that they create a huge number of semantic complications and they essentially render the behavior of the program un-analyzable. Finally, they break the C stack utterly, and the C stack isn't going away anytime soon. We rejected them in BitC for all of these reasons, the absence of any use-case being the most compelling. >From personal experience, the only interesting use of real continuations that I can remember was interrupt dispatch in MacScheme, and having done my time building microkernels I think that wasn't a good idea. On to threads. If you have threads then you have stacks. Each thread will need a stack and a heap. While it is possible to allocate the stack out of the heap, the performance of this is problematic. If you choose to generate C code, you are either going to use the C stack at procedure calls or you are going to hand-implement procedure calls on some other stack. The latter is *far* more expensive than using the C stack. So I am missing something. I don't see a performance-motivated argument for avoiding the C stack. The only argument I see concerns continuations, and continuations raise a whole bunch of concerns and problems. Can you explain a bit more the problem you anticipate with the C stack?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
