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
