<div dir="ltr">Hi Ben,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<a href="mailto:commits@squeakvm.org" target="_blank">commits@squeakvm.org</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Revision: 3152<br>
Author: eliot<br>
Date: 2014-11-26 11:57:25 -0800 (Wed, 26 Nov 2014)<br>
Log Message:<br>
-----------<br>
Make sure to compile the SmallFloat64 primitives.<br>
<br>
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.'<br>
stamp: 'eem 11/25/2014 7:54'.<br>
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.'<br>
<br>
</blockquote>
<br>
So are SmallFloats converted to BoxedFloats on the fly when an image is moved from a 64-bit host to a 32-bit host ?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">btw, Does that comment need updating... didn't you go with SmallDouble, BoxedDouble?<br></blockquote><div><br></div><div>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.</div></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>