Dan Sugalski <[EMAIL PROTECTED]> wrote: > *) Opcodes are limited to 32 bits so we have full bytecode > portability. While defining an opcode number past 2 billion is > utterly insane, we don't require that there be no holes in the opcode > numbers,
Huh, what did I miss here: # define DO_OP(PC,INTERP) (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP)) or several over places. I see no chance (nor any value) in holes in opcode numbers. > *) Integer constants are limited to 32 bit signed integers because > they're inline. Yep. But this will cause problems with JIT/Prederef and multi threading, and its already causing problems inside JIT on architectures with only small immediate constants. We have to consider these upcoming problems too. I dont see any reason, not to have optionally/additionally - or always - integers in the const_table. > *) INTVAL is meant to be the fastest native integer type for integer > math that's at least 32 bits. That integer registers are INTVALs is > an unfortunate side-effect, and one I'm tempted to do something about. In one of the FUPs, I had a different definition: An INTVAL is the size of the integer register. The fastest integer type on $arch ought to be just a plain C<int>. I think, when we look at the problem from this side, it should be simpler. > 4) Have separate 32 and 64 bit I registers > 5) Do guaranteed 64 bit math in PMCs > 4 isn't that bad. Not great, as it's more registers, and something of > a waste on 64 bit systems, but... Not a waste. amd-64 aka x86-64 has 32bit ints and 64bit longs and pointers (gcc). This architecture could fully exploit both integer types. If memory consumption (register in saving) is a big issue, reducing the amount of LONG (and N, S) registers could be an option, though I really don't like the irregularities, this would cause. But it should be worth some thoughts: The probably most used types will be PMCs and IREGs, followed by nothing first, then N or S or L dpending on the program. > #5 is something of a cop-out, but I'm not quite sure how much. It will slow down the usual untyped interpreter (PMC) scalars a lot. I'm - as stated in the thread - for a new register type (L, long). They have the same relation as 32bit ints and 64 bit longs, with the difference that we guarantee at least these sizes. leo
