[Vm-dev] 64bits spur DataStream assumes SmallInteger fit in 32bits

David T. Lewis lewis at mail.msen.com
Sat Oct 31 23:52:53 UTC 2015


On Sat, Oct 31, 2015 at 07:20:11PM +0100, Nicolas Cellier wrote:
>  
> Hi,
> as the title tells,
> 
> DataStream>>writeInteger: anInteger
>     "PRIVATE -- Write the contents of a SmallInteger."
> 
>     byteStream nextInt32Put: anInteger    "signed!!!!!"
> 
> Which strategy do we adopt?

I think that your strategy makes good sense, and I will try to repeat it
here to confirm my understanding:

When writing integers out to serialization, the external representation
will be that of the V3 32-bit object memories. Integer objects with values
in the range -16r40000000 through 16r3FFFFFFF will be stored externally as
SmallInteger, and integer objects beyond that range (which might be small
integer objects for 64-bit Spur, or large integer objects otherwise) will
be stored as large integers (LargePositiveInteger or LargeNegativeInteger,
or some similar fake representation).

When materializing integers, the small or large integer objects will be
instantiated as integer objects in whatever format is suitable for the
current object memory. Integers that were stored as SmallInteger will
always be SmallInteger. Large integers will be instantiated as whatever
may be appropriate for the image format.

For 32-bit V3 object memory, no conversion is required. For 64-bit Spur
object memory, integers will be instantiated as SmallInteger if they
fit within the range of SmallInteger values for the 64-bit Spur memory,
otherwise they will be instantiated as LargePositiveInteger or
LargeNegativeInteger.

This policy means that integer objects are stored externally in a format
compatible with 32-bit object memories, and converted on input as required
for 64-bit object memories.

Dave



> I suggest using a fake LargeInteger...
> 
>     objectToStore := (self objectIfBlocked: anObject) objectForDataStream:
> self.
>     objectToStore == anObject ifFalse: [typeID := self typeIDFor:
> objectToStore].
> 
> Of course, we must also care of LargeInteger materialization in 64bits spur.
> I'm going to fix it unless someone has a better idea.
> 
> Nicolas



More information about the Vm-dev mailing list