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,
Ian
More information about the Vm-dev
mailing list