Porting Squeak to IA64
ian.piumarta at inria.fr
Fri Jan 16 14:32:59 UTC 2004
On 16 Jan 2004, at 02:32, Alan Grimes wrote:
> Virumandi Sandiyar wrote:
>> I am newbie to Squeak and I am trying to
>> port squeak to an Intel Itanium2 (64-bit) cpu-base
>> server running on 64-bit Linux.
>> 1. First of all, I would like to know if it is
>> feasible to port Squeak to IA64 and if there is any
>> benefit in it.
Not really (unless you *absolutely* need images >= 2 Gbytes in size).
And it would be a LOT of work.
A year or two ago I ported Squeak to the Cray T3E and SV1 machines, and
the problems were significant. Many of these were related to 32-bit
oops and SmallIntegers in the image having 64-bit equivalents within
the VM. (I won't go into the problems related to pointers being
totally wierd on the SV1, where casting between "char *" and "int"
isn't at all obvious. ;) It took me a couple of weeks just to bring an
image up, with lots of plugins still known to be broken in the VM.
The approach I took was to make a 64-bit VM implementation understand a
32-bit image by wrapping every single memory access with a few extra
insns needed to widen/narrow integers and pointers, and performing
base+index addressing of memory on one of the machines where the image
(and VM -- which generates function pointers at runtime and stores them
in the image) couldn't be forced into the first 31 bits of address
space. Changing the image to support 64-bit oops directly would have
represented an inconceivable amount of work and simply wasn't an option
in the time available. There was a significant performance penalty
involved in coping with the "impedance mismatches" between the 32-bit
quantities in the image and the 64-bit representations of them within
> I suspect that it will run out of the box
Correct. The IPF processors manufactured by Intel (e.g., Itanium)
include a 386 compatibility mode and will execute 32-bit programs
directly on the hardware. Both Linux and XP (AFAIK) have the OS
support needed to make the compatibility mode work seamlessly with the
underlying 64-bit kernel. Ignoring the inefficiencies inherent in the
compatibility mode (compared to executing directly on 32-bit hardware),
you pay nothing in performance except for a small amount of implicit
data reorganisation when switching between userland and kernel across
syscalls and interruptions.
FWIW, I already tried running a VM compiled for Pentium on a
4-processor SMP Itanium box under RedHat Linux. It works *perfectly*.
(The only caveat is that you cannot recompile the VM using the native
compiler. You have to compile it on a 386-class machine, or install a
cross compiler on the Itanium that emits 32-bit 386 code.)
>> 4. Do I need to port the image also to make it work on
>> the 64 bit platform?
> No, absolutly not.
> The immage runs unmodified on all platforms except PDAs due to memory
But if you wanted to do it properly, then porting the image to 64-bit
oops and 63-bit SmallIntegers would be part of the deal (and would be
*much* more difficult than simply making a 64-bit VM understand a
FWIW, the Solaris VM is compiled for pure 32-bit execution. The Alpha
VM is (was ;) compiled using the vendor's compiler which has a
"migration" option that provides 32-bit pointers in the compiler and
forces the loader to place everything in the first 32 bits of the
address space -- effectively making a 32-bit application that will run
on a 64-bit cpu. (The VM cannot be compiled for Alpha using gcc, since
this compiler feature is missing.)
More information about the Squeak-dev