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
|