64 bit images(was: A plan for 3.8/4.0...)

Jecel Assumpcao Jr jecel at merlintec.com
Fri Apr 2 16:20:13 UTC 2004


On Friday 02 April 2004 04:33, Dan Ingalls wrote:
> Ian is going to be helping me through the hard parts and, as he says,
> if we do it right, the G5 and any other 64-bit machine ought to run
> right out of the box.

Like my Sun Ultra 5 :-)

One issue is sharing images between machines with different word sizes. 
I had to deal with this issue in Neo Smalltalk and can share images 
(image segments, actually, but close enough) between the 16 and 36 bit 
implementations.

Given the current ratio of cpu and disk speeds, I considered it 
reasonable to do some computing while reading/writing images and so 
came up with a compressed format for them. Integers are encoded to take 
up the smallest number of bits possible without imposing any limit this 
size. Something like (example made up on the spot):

  0 <4 bit integer>
  100 <8 bit integer>
  101 <12 bit integer>
  110 <16 bit integer>
  11100 <32 bit integer>
  11101 <64 bit integer>
  11110 <8 bit size (in bytes)> <n bit integer>
  11111 <32 bit size (in bytes)> <n bit integer>

I actually use the same encoding for floats as well as the contents of 
strings and bitmaps, but that isn't important here.

When reading in an image, any integer that can fit into the SmallInt 
representation is converted to that while all others are translated to 
LargeInt objects and a pointer to that is inserted into the field that 
is being read. When saving the image everything is converted to this 
format. So an object that is a SmallInt on one machine can become a 
LargeInt (or the other way around) when saved to an image that is read 
in a different machine. This is where the fact that we are in Smalltalk 
and dealing with real objects all the way down comes in handy. Of 
course, the primitives have to be less picky about only dealing with 
SmallInts as arguments, but that is a good change to make anyway.

-- Jecel



More information about the Squeak-dev mailing list