Fwd: Handling non-standard integer types

[Andy Dougherty]

On Sun, 12 Feb 2012, Jonathan Worthington wrote:

> 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.


Although a search in the github issues won't turn it up, there's a Trac 
ticket TT #1047, which refers to an RT ticket [perl #56810], which is no 
longer available, which described the situation a bit more.  In brief,
such mixed configurations used to work a long time ago, but haven't worked 
for many years.

I know of no fundamental reason why INTVAL = 64bit, opcode_t = 16 or
32 bit couldn't work, but it's tricky.  For example, alignment is one
tricky spot.  If you're reading in 16-bit chunks, but assigning to
entities that require 32- or 64- bit alignment, then you've got to take
special care, at least on some processors, such as SPARC and PPC.

-- 
    Andy Dougherty		doughera at lafayette.edu