3.8a-1 (Unix) and 32-bit compatibility for 64-bit support code (all platforms)

Ian Piumarta ian.piumarta at inria.fr
Tue Mar 22 23:06:26 UTC 2005

[apologies for multiple reception.  if it's possible to subscribe to 
this list with several posting email addresses for just a single 
reception address, someone please point me at the relevant stuff]

VM Hackers,

The trunk of the unix tree is now at (an unstable, monotonically 
advancing) 3.8a-1.  I'm telling you this because there are significant 
widespread changes since 3.7-7.  In particular, the core Unix VM 
support is the result of merging 3.7-7 with my previous 64-bit support 
code released a while ago.  This 64-bit compatible code is now the 
official support code for Unix versions 3.8 and onwards.

While waiting for Tim to pull the changes Dan and I sent him into the 
Interpreter and CCodeGenerator, I've pre-emptively checked in 
Cross/vm/sqMemoryAccess.h, which is a slightly modified copy of the one 
I released with the original 64-bit code.  It allows the support code 
to use the new type names, but still compile with a 'src' tree 
generated from a 32-bit Interpreter/CCodeGenerator.  There may be a few 
unexpected warnings about mixing integers and pointers for the moment, 
but these are harmless.

Needless to say, if your support code is still of the old 32-bit 
flavour, it won't ever include this header file.

Note that this does not mean you can compile a 64-bit VM for 32/64-bit 
hardware, nor does it mean you can run a 32-bit VM on 64-bit hardware.  
The only thing it kludges into working order is compiling 32-bit 'src' 
to run on 32-bit hardware, mixing 'int's in the generated stuff with 
'sq{Int,Long,Whatever}'s in the support code.  For all four 
combinations of 32/64 VM + 32/64 h/w to work, we have to wait for our 
64-bit image changes to percolate into the released image-side stuff.

Backwardly-compatible cheers,

More information about the Vm-dev mailing list