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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
