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

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


More information about the Vm-dev mailing list