Porting Squeak to IA64

Ian Piumarta 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 
the VM.

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

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 
32-bit image).

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

Cheers,
Ian




More information about the Squeak-dev mailing list