<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">&lt;<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>&gt;</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: &#39;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.&#39;<br>
                stamp: &#39;eem 11/25/2014 7:54&#39;.<br>
        smallFloat comment: &#39;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.&#39;<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 &quot;automatically&quot; (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&#39;t think one will ever want this to happen automatically.</div><div><br></div><div>Further, I hope and expect that we&#39;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&#39;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>