FloatArrayPlugin & 64bitting
Ian Piumarta
ian.piumarta at inria.fr
Fri Apr 29 16:28:15 UTC 2005
Hi Dave,
On Apr 29, 2005, at 09:08, Dave Mason wrote:
> I assume that sqInt is
> defined as equivalent in size to a pointer (since that is the point),
Almost. sqInt is defined to be the same width as an object pointer.
Because of the 4-way compatibility (you can run 32- or 64-bit images on
32- or 64-bit hardware) the width of an oop is not the same as the
width of a raw pointer in 2 of the 4 cases.
The tricky case is running a 32-bit image on 64-bit hardware, where the
object memory is almost certainly mapped way above the range of 32-bit
addresses. To deal with this, sqMemoryAccess.h has macros to deal with
translating 32-bit oops to/from 64-bit addresses, based on the address
at which the object memory has been allocated by the OS. For 64-bit
cleanliness it is imperative never to cast explicitly between pointer
and non-pointer (which includes ints and oops) otherwise a required
translation might not occur. sqMemoryAccess.h defines two macros to
replace such casts:
sqInt oopForPointer(char *rawPoitner)
and
char *pointerForOop(sqInt anOop).
These are effectively no-ops on all combinations other than the
"tricky" one described above.
> so casting it to an sqInt should be exactly correct.
Except as noted above.
> I also assume that firstIndexableField returns a type that is
> compatible with sqInt.
It returns the address (as a pointer) of the first indexable field.
Pointers are always the width of hardware pointers; oops are always
integers of the same width as an object pointer as stored in the
virtual image. The two are orthogonal. The only way to convert
between the two forms is via the two macros described above. Anything
else will break on some combination of 32-/64- image and 32-/64-
hardware.
Sorry this is turning out to be so confusing! (I was going to rename
sqInt to sqOop or something similar, which I think would have lessened
the confusion, while I still had the "Interpreter/CCGen token", but got
distracted by other things...)
Cheers,
Ian
More information about the Vm-dev
mailing list