Fwd: Handling non-standard integer types

[Jonathan Worthington]

On 2/12/2012 4:46 PM, Andrew Whitworth wrote:
> It depends what you mean about "plans ... to support more than integer
> type". There are a few ways we could support a 64-bit integer:
>
> 1) Add a new register set for consistently-sized large integer types
> (i.e. $Ix is for system-sized integers, but $Lx would always be for
> large 64-bit integers). This would be a hassle to implement.
The bigger win (with corresponding bigger hassle) is to drop the "4 
register types" notion, add a way to declare registers of different 
types that's richer than the 4, and switch to the "register frame" just 
being a blob of memory and register accesses are offsets into that. 
Unfortunately, that may well be hard to make efficient in an interpreter 
context (though prederef stuff could well be an option).

> 2) Change configuration to always force the $I register set to be
> 64-bits wide. This would waste a lot of space where such large
> integers weren't needed, and might be inefficient on platforms without
> good 64-bit arithmetic support.
Of the three, this feels like the most immediately feasible option; 
it'll get us something workable, and we can add some ops to cope with 
the unsigned cases when they're different. Note that in terms of space, 
you probably tend to care more when you're storing large numbers of 
integers, e.g. in packed arrays.

The problem isn't so much changing the $I registers; it's that on 64-bit 
the opcode_t also changes with that at the moment. Which means that 
bytecode is hugely padded on 64-bit systems (in fact, 16 bits for opcode 
woulda probably been enough; 32 is maybe OK; 64 is nuts). This is 
already an issue for everyone on 64-bit, so it'd just be giving 32-bit 
folks the same pain. But maybe pain leads to more incentives to improve 
things. ;-) Note that fixing this would imply that 64-bit integer 
literals need a constants segment entry. But I think it'd be worth it; 
the win is less memory usage and more bytecode fitting in the CPU cache, 
which is important.

> 3) Keep the $I register set the same (platform/config-dependent) but
> add in Int64 (and Int32, etc) PMC types. These might be a replacement
> for or a supplement to our current Integer PMC type. (We would need to
> work out all sorts of boxing and autoconversion rules, and PMC
> operations are inherently less efficient than $I registers, etc)
This one isn't going to work out from a Rakudo perspective. If that's 
all that's possible then I can do the same far more neatly with a REPR 
in 6model. But the reason I don't want that is that I want to be able to 
do operations on 64-bit ints, signed or unsigned, as *integers*, not as 
objects (which in turn require allocation and GC). That's the key part here.

Thanks,

Jonathan