Smalltalk › Squeak › Squeak - Dev

Re: [Vm-dev] [commit][3152] Make sure to compile the SmallFloat64 primitives.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Eliot Miranda-2

Re: [Vm-dev] [commit][3152] Make sure to compile the SmallFloat64 primitives.

Hi Ben,

On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman <[hidden email]> wrote:

[hidden email] 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

Bert Freudenberg

Re: [Vm-dev] [commit][3152] Make sure to compile the SmallFloat64 primitives.

On 26.11.2014, at 23:42, Eliot Miranda <[hidden email]> wrote:

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.

Here’s my message (sent private to Eliot to not prolong the bikeshedding):

From: Bert Freudenberg <[hidden email]>
Subject: Re: Float hierarchy for 64-bit Spur
Date: 24. November 2014 11:50:34 MEZ
To: Eliot Miranda <[hidden email]>

On 21.11.2014, at 19:08, Eliot Miranda <[hidden email]> wrote:
I think I'll go with

Float
|
+------- BoxedDouble
|
+——— SmallDouble

Sounds okay. I just had another thought: use "Float64" instead of "Double". That is how JavaScript names it, and I like how it communicates exactly what it is without having to implicitly know about the IEEE standard's nomenclature. Also, with the digits in the name it screams "low level", and would easily extend to 32 and 128 bit floats.

Float
|
+------- BoxedFloat64
|
+——— SmallFloat64

- Bert -

- Bert -

smime.p7s (5K) Download Attachment