Melvin Smith <[EMAIL PROTECTED]> wrote: > At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote: > Ix regs are for: > 1) Fast integer stuff > 2) Iteration (increment variables) > 3) Conditional checks > 4) Branching and holding addresses > 5) Indexing arrays and strings
While the operands clearly are of wordsize (opcode_t) I doubt that it makes sense to say, that arrays or strings can hold max-INTVAL items.
Maybe not, but the point is that you want the efficient wordsize for
your INTVAL in those cases (ie. _not_ 64-bit on 32-bit architecture, or vice-versa).
> All of this works out fine if we use the native size, and none of this > should be penalized (for example if we decided to use "default" 64-bit > INTVAL registers > on a 32-bit CPU, this is penalization -- which I am NOT proposing).
The question is: Do we want to support a configuration with 32-bit opcode_t and 64-bit INTVALs? Perl5 has 64-bit IV support, but it doesn't has native data types. Perl6 may have both. The languages, we are running will define, if we need such a configuration.
The languages don't get to decide for Parrot, though. Parrot should guarantee existence and size of INTVAL and HUGEINTVAL registers. How a HLL maps to Parrot registers (or PMCS) is its own business.
To your 1st question, I don't think we should support any case where sizeof(opcode_t) != sizeof(INTVAL). Both of these should be the most efficient wordsize, so on each platform they should match.
The 2 cases you are describing would be:
a) 64-bit INTVAL on 32-bit platform (suboptimal)
& 32-bit opcode_t (ok)b) 64-bit INTVAL on 64-bit platform (ok)
& 32-bit opcode_t on 64-bit platform (suboptimal)Neither of these is a valid configuration IMO.
**We should always guarantee both opcode_t & INTVAL will be optimal for speed. We never have to guarantee HUGEINTVAL will be.
-Melvin
