Okay, after reading the thread, I think some explanations and notes are in order.
*) 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, so theoretically a platform could load in an opcode library and start its numbers at, say, 2^37. I didn't want that to happen.
*) Integer constants are limited to 32 bit signed integers because they're inline. I couldn't think of enough likely reasons to have an integer constant outside the range of +-2^31. For those, I'm figuring people can use PMC or float constants
*) 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.
*) The IRC conversation that Gopal quoted is actually a fairly important one. The engine needs to deal with 64 bit integer math natively, as well as 32 bit integer math. (Smaller math sizes--16 and 8 bits--are easy enough to deal with regardless of what we do)
The last is the important bit. I want, and I think we need, to do 64 bit math. I'm not 100% sure that we actually need to do it as a plain integer rather than as a PMC, but I'm not 100% sure we don't either.
Our options, as I see them, are:
1) Make the I registers 64 bits 2) Make some way to gang together I registers to make 64 bit things 3) Have I registers switchable between 32 and 64 bit somehow 4) Have separate 32 and 64 bit I registers 5) Do guaranteed 64 bit math in PMCs
The first is just out. It's an unreasonable slowdown on 32 bit (and some 64 bit) machines, for no overall win. The majority of integers will be smallish, and most of even the 32 bit range will be wasted.
I don't like option 2, since it means that we speed-penalize 64 bit systems, which seems foolish.
Option 3 wastes half the L1 cache space that I registers takes up. Fluffy caches--ick. Plus validating the bytecode will be... interesting, even at runtime.
4 isn't that bad. Not great, as it's more registers, and something of a waste on 64 bit systems, but...
#5 is something of a cop-out, but I'm not quite sure how much.
From what I can think, we need guaranteed 64 bit integers for file offsets, JVM & .NET support, and some fairly special-purpose math stuff. I'd tend to discount the special-purpose math stuff--that's not our target. JVM and .NET don't do much 64 bit stuff, but they do some. The file offset parts are in some ways the least of it, though we do need to have some internal support for 64 bits to get integer values out of PMCs without loss.
Anyway, I'm still somewhat conflicted. Opinions?
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
