On Sun, 23 Sep 2001, Bart Lateur wrote:
> On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
> Jarkko Hietaniemi wrote:
>
> >I always see this claim ("why would you use 64 bits unless you really
> >need them big, they must be such a waste") being bandied around, without
> >much hard numbers to support the claims.
>
> >Unless you are thinking of huge and/or multidimensional arrays
> >of tightly packed integers, I don't think you should care.
>
> We're talking bytecode. That will indeed be a case of "huge arrays of
> tightly packed integers".
I was under the impression that the byte-code was all goin to be
integer-based (op-code-id, reg-id, 32bit-int-constants, etc). Anything
else should be in the constant pool. I'm not sure how damaging 32bit
pointers are in a 64bit arch, but the byte-stream "addresses" are simply
32bit offsets. I can't imagine a 4.1Gig opcode chain.
Thus as long as we allow long long int and [long] double in the constant
block, I don't see a problem with compatibility between 32/64bit archs.
The constant-declaration should be able to specify the granularity.
-Michael
