Hi Ben,
On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman <btc(a)openinworld.com> wrote:
>
> commits(a)squeakvm.org wrote:
>
>> Revision: 3152
>> Author: eliot
>> Date: 2014-11-26 11:57:25 -0800 (Wed, 26 Nov 2014)
>> Log Message:
>> -----------
>> Make sure to compile the SmallFloat64 primitives.
>>
>> boxedFloat comment: 'My instances hold 64-bit Floats in heap
>> objects. This is the only representation on 32-bit systems. But on 64-bit
>> systems SmallFloat64 holds a subset of the full 64-bit double-precision
>> range in immediate objects.'
>> stamp: 'eem 11/25/2014 7:54'.
>> smallFloat comment: 'My instances represent 64-bit Floats whose
>> exponent fits in 8 bits as immediate objects. This representation is only
>> available on 64-bit systems, not 32-bit systems.'
>>
>>
> So are SmallFloats converted to BoxedFloats on the fly when an image is
> moved from a 64-bit host to a 32-bit host ?
>
No; there is no automatic conversion between 32-bit and 64-bit images.
64-bit Spur images will only be runnable on 64-bit machines. There are
scripts that convert 32-bit non-Spur images to 32-bit Spur images and from
32-bit Spur images to 64-bit Spur images, and it would be easy to add a
script that converted from a 64-bit Spur image to a 32-bit Spur image. But
none of these conversions will be provided "automatically" (e.g. as a
side-effect of starting up an image), although they may be wrapped up in
tools. Currently the conversion time from 32-bit non-Spur to 32-bit Spur
on a fast laptop is 5 minutes, and IIRC conversion from 32-bit Spur to
64-bit Spur takes a couple of minutes. So I don't think one will ever want
this to happen automatically.
Further, I hope and expect that we're moving to/have already moved to a
construction-oriented image build process where one will take a
pre-prepared base image of the appropriate pointer width and run scripts to
load packages into them. So I expect the main use of the Spur 32-bit to
64-bit bootstrap is in preparing base release images.
btw, Does that comment need updating... didn't you go with SmallDouble,
> BoxedDouble?
>
No. Bert suggested (IIRC) ImmediateFloat64 and BoxedFloat64 and I went
with SmallFloat64 and BoxedFloat64 for two reasons. SmallFloat64 because I
like the symmetry with SmallInteger, and because this name scheme
gracefully admits SmallFloat32, BoxedFloat32 and BoxedFloat80 if ever there
was the energy to add them.
--
best,
Eliot