At 04:48 PM 6/5/2002 +0200, Jerome Vouillon wrote: >My feeling is that the current implementations of stacks are not >adequate: >- the control stacks store too many registers at once;
They are register windows, so I think they work fine for that purpose. It doesn't mean the control stack must be used everywhere. >- the generic stack is typed, so it is slow; I agree here, sort of. Since I didn't write it, I can't comment, except I'd like to hear the pros and cons of a typed vs. non-typed stack. We are already assuming that the compiler will generate valid internal state, so why check stack entries? Possibly there can be a compile time option for developers to use a typed stack, which would not exist at runtime in the general distribution? >- 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. This part I definitely agree with. While its not true that there is NO support, it makes writing a register spiller more compilicated when you have to worry about the order in which you spill, and interference. There >So, I propose to replace them by a single stack. Here is a design >proposal. What do you think about it? Looks like C calling convention, give or take a bit. >Floats >====== >On a lot of architectures, they are twice as large as integers and >pointers. So, we have two options: >- make the stack entries large enough for floats (this wastes memory) >- use to stack entries to store floats (we then need to be careful > with memory alignement) The JVM does the latter. I think the first option is not attractive because it bloats the stack since Floats are in the minority. I think there are some valid concerns here. -Melvin
