At 4:48 PM +0200 6/5/02, Jerome Vouillon wrote: >My feeling is that the current implementations of stacks are not >adequate: >- the control stacks store too many registers at once;
The control stack doesn't store any registers at all. I presume you're talking about the four register frame stacks. >- the generic stack is typed, so it is slow; Yep, hence the integer stack. Access to the generic stack can and should be faster. I'm thinking of some call-framing stuff to speed it up. >- none of these stacks provide any support for register > spilling/reload: there is no opcode to get or set the > n-th element of a stack. Which is just a deficiency in the opcode set, or would be if we didn't have one of these opcodes. Though arguably the rotate_up op is a bit less than spiffy, in which case all we need to do is add an op. (So I will) >So, I propose to replace them by a single stack. Here is a design >proposal. What do you think about it? Nope. :) Seriously, a linear stack, even a chunked one like we have, makes continuations a major pain. Continuations are going to be more prevalent as soon as exceptions come online in the next few days. Also, the problem with a single untyped stack is garbage collection. Right now, *all* entries on the stack are typed, either implicitly (the PMC and String frame stacks) or explicitly (the user stack). Forcing the GC to intuit whether a pointer on the stack is for a PMC or string (or is, in fact, even a pointer) is a rather time-intensive thing and, given how rarely the stack's likely to be used anyway, I don't see it as a big issue. Could be wrong, of course. Wouldn't be the first time. I'll need more convincing for that, though. -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk