Continuations, concurrency, yada yada...

[Lee Salzman]

The instruction set is hardly an issue, even on the x86, since it all 
just boils down to microcode anyway. The problem (which you're not gonna 
escape on PPC and ARM either) comes from other places. What once was a 
small compact thing that fit nicely in the cache (the stack) with much 
space left over for other things, is now an expansive run of memory, the 
size of which is inversely correlated with the number of GCs that must 
take place to maintain it. Then, also, your stack can no longer just be 
"naked data". Everything has to be properly identifiable to the GC. I am 
just trying to point out that whatever you're using, there's still a 
cost to straying from a stack architecture.

And that's neglecting the issue of whether continuations are even the 
appropriate concept, as there are roughly equivalent things that do not 
require grossly reorganizing the architecture in that manner.

Really, I'm not looking for a discussion of how to implement these 
concepts, since I am well aware of how to do so already. What I am 
looking for is a diagogue on what is the RIGHT concept to implement, IF ANY.

Lee

Tony Garnock-Jones wrote:
> Lee Salzman wrote:
> 
>> [for implementing continuations] You're either faced with copying
>> large parts of the stack (you might consider that a vote for
>> delimited continuations, if any) or getting rid of the stack entirely
>> in favor of a garbage collector nursery.
> 
> 
> Yes.
> 
>> I am not even sure what havoc the catastrophic overhaul option would
>> play on a dynamic compiler.
> 
> 
> I can't imagine the changes required would be any more taxing than those 
> required to support a different continuation representation in an 
> interpreter.
> 
> One of the things that I like about the PPC (and ARM, for that matter) 
> is that it doesn't insist on having a stack - conventionally one of the 
> registers is used to manage a stack, but that's totally up to the ABI 
> designer...
> 
>> But if one just wants poor man's threads, then real threads are
>> better. Real threads need to be implemented at some point, and having
>> a feature which is poorly orthogonal to real threads does not bode
>> well for that feature.
> 
> 
> The Interpreter structure is currently 15 words long. The stack 
> autogrows, and could be started at, say, 16 words. Maybe we're not so 
> far away from at least cooperative multithreading.
> 
> Tony
> 
>