> 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.
>  
>
I was looking at the same problem in my image modifications... My first 
instinct was to do the x86 thing and just add opcodes for the longer 
formats... So we would have bitAnd32 and bitAnd64.....

Yes, it is possible to do it both ways....

I am still trying to puzzle out why the "positive32BitInt" function 
seems to do a byte-order conversion when faced with a long int....

Futhermore, why is there a negative long int class?