Dan Sugalski <[EMAIL PROTECTED]> wrote:Okay, here's a really, really evil idea. (And yes, bluntly, it's triggered by the pie-thon bytecode translator's needs) I need a stack,
Do you? I've converted all stack stuff at compile time, till now. I don't see the point, why this might not work for all opcodes.
There's the issue of basic block analysis which, bluntly, I'm not comfortable counting on being able to do in the time I've got. I may do a quick scan tonight, if I have time to hack it up, to see what the stack looks like going into the blocks. If a block's got multiple entry points then I need to coordinate register usage across all the places that could call it, which I'm not sure I've time for.
> ... and one that's faster than our current stack which, whilesnappy for what it does, is still burdened by generality. I also need a stack that's generally not very big. So...
Generally. Have a look at BUILD_TUPLE or BUILD_LIST. The limited stack will not work, you have to do overflow checking all the time and you'll have 2 addressing modes, one in registers and one in overflow.
I know there are a few nasty ones. I'm sorely tempted to toss the alignment bit and make the stack the same number of registers as we use for calling conventions, and turn those two into subs, in which case the setup for the call is a quick copy of the stack registers to the calling registers, with the overflow array matching for both.
> iset Px, Iy
This does a set of register Px to PMC register #Y.
C<setp_ind> *is* in set.ops. If above is the other direction, then that should be named accordingly.
I thought that was in there, but I missed that one. I'll add in its complement. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
