Smalltalk › Squeak › Squeak VM

[commit][3152] Make sure to compile the SmallFloat64 primitives.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

commits-3

[commit][3152] Make sure to compile the SmallFloat64 primitives.

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.

Modified Paths:
--------------
branches/Cog/image/MorphFloat.st

Modified: branches/Cog/image/MorphFloat.st
===================================================================
--- branches/Cog/image/MorphFloat.st 2014-11-26 01:09:16 UTC (rev 3151)
+++ branches/Cog/image/MorphFloat.st 2014-11-26 19:57:25 UTC (rev 3152)
@@ -102,7 +102,27 @@
[:s :m|
m methodClassAssociation: binding].
bfc organization removeEmptyCategories; sortCategories].
+ "shrink method dictionaries after removals; rehash does not shrink :-("
+ {boxedFloat. boxedFloat class} do:
+ [:bfc| | nmd |
+ nmd := MethodDictionary new.
+ bfc selectorsAndMethodsDo:
+ [:s :m| nmd at: s put: m].
+ bfc methodDict: nmd].

+ "Compile the SmallFloat64 primitives.
+ These have primitive number 500 + the corresponding boxed primitive number"
+ boxedFloat selectors do:
+ [:s| | code |
+ code := (boxedFloat sourceCodeAt: s) asString.
+ code := code copyReplaceAll: '<primitive: ' with: '<primitive: 5'.
+ smallFloat
+ compile: code
+ classified: (boxedFloat organization categoryOfElement: s)
+ withStamp: 'eem 11/25/2014 7:54'
+ notifying: nil].
+ smallFloat organization sortCategories.
+
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.'

Ben Coman

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

[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 ?

btw, Does that comment need updating... didn't you go with SmallDouble,
BoxedDouble?

cheers -ben

Eliot Miranda-2

Re: [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: [squeak-dev] [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

Andres Valloud-4

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

In reply to this post by Eliot Miranda-2

I'd rather this didn't happen... now we will always have to remember
that "float32" is really what everybody else calls "float", "float64" is
really what everybody else calls "double", and "float80" is... who
knows... maybe the x87 extended double...

It is a "double", what's the problem with calling it a "double"?

On 11/26/14 14:42 , Eliot Miranda 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.

Bert Freudenberg

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

> On 28.11.2014, at 02:17, Andres Valloud <[hidden email]> wrote:
>
> I'd rather this didn't happen... now we will always have to remember that "float32" is really what everybody else calls "float", "float64" is really what everybody else calls "double", and "float80" is... who knows... maybe the x87 extended double...
>
> It is a "double", what's the problem with calling it a "double"?

It's called "double" in C, not universally. Which doesn't tell you anything unless you know that it might refer to what the IEEE standard calls "double precision". It also defines the 32 bit format as "single precision", so you might conclude C would call that "single", right? Nope.

All of these are floating point numbers, so calling them Float makes sense. And giving the number of bits is precise and allows extending to other widths easily.

There are programming languages with naming schemes more sensible than C has. E.g. Python has only "float" (which is 64bits) but NumPy defines "float32" and "float64". Same goes for Java and JavaScript, or more recently, Go. Naming low-level types by their bit width is well-established.

- Bert -

>
> On 11/26/14 14:42 , Eliot Miranda 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.

smime.p7s (5K) Download Attachment

Eliot Miranda-2

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

In reply to this post by Andres Valloud-4

On Thu, Nov 27, 2014 at 5:17 PM, Andres Valloud <[hidden email]> wrote:

I'd rather this didn't happen... now we will always have to remember that "float32" is really what everybody else calls "float", "float64" is really what everybody else calls "double", and "float80" is... who knows... maybe the x87 extended double...

I don't see this. Squeak has had Float for a long time, and for those that know C that's confusing since float there-in means 32-bit single-precision, whereas in Squeak Float means 64-bits (double precision). But as Bert said, Float64 is what JavaScript calls double-precision, and BoxedFloat64 and SmallFloat64 are good descriptive terms. They don't match VisualWorks, but that's not been a problem in practice.

It is a "double", what's the problem with calling it a "double"?

Double's not got a good dual for single-precision. SIngle is a poor name. that's what really made me lean to Bert's suggestion, that if wanted we can add Float32, or even Float80, and Float32 is a much better name than Single. SinglePrecisionFloat is a mouthful. What we have now means that Squeak and Pharo (and perhaps Newspeak) code will continue to use Float, since the concrete names don't need to be used, or even recognized, except in specialized contexts (e.g. intra-dialect copying?), since Floats print themselves literally.

Also, using C's names isn't a good rationale. It may work for VM implementors but has nothing of value for Smalltalk programmers.

On 11/26/14 14:42 , Eliot Miranda 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.

best,

Eliot

Ben Coman

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

In reply to this post by Bert Freudenberg

Bert Freudenberg wrote:

>
>
>
> ------------------------------------------------------------------------
>
> On 26.11.2014, at 23:42, Eliot Miranda <[hidden email]
> <mailto:[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):

AhHA! You let the cat out of the bag then....
Sorry, I just had to pull that bike out one more time...

>
>> From: Bert Freudenberg <[hidden email]
>> <mailto:[hidden email]>>
>> Subject: Re: Float hierarchy for 64-bit Spur
>> Date: 24. November 2014 11:50:34 MEZ
>> To: Eliot Miranda <[hidden email]
>> <mailto:[hidden email]>>
>>
>>
>> On 21.11.2014, at 19:08, Eliot Miranda <[hidden email]
>> <mailto:[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
>>
>>

(only half tongue-in-cheek) Should SmallFloat61 have been considered?

cheers -ben

Eliot Miranda-2

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

Hi Ben,

On Dec 5, 2014, at 5:52 AM, Ben Coman <[hidden email]> wrote:

> Bert Freudenberg wrote:
>> ------------------------------------------------------------------------
>> On 26.11.2014, at 23:42, Eliot Miranda <[hidden email] <mailto:[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):
>
> AhHA! You let the cat out of the bag then....
> Sorry, I just had to pull that bike out one more time...
>
>>> From: Bert Freudenberg <[hidden email] <mailto:[hidden email]>>
>>> Subject: Re: Float hierarchy for 64-bit Spur
>>> Date: 24. November 2014 11:50:34 MEZ
>>> To: Eliot Miranda <[hidden email] <mailto:[hidden email]>>
>>>
>>>
>>> On 21.11.2014, at 19:08, Eliot Miranda <[hidden email] <mailto:[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
>
> (only half tongue-in-cheek) Should SmallFloat61 have been considered?

No! :-). Two reasons, a) if you send at: to a SmallFloat64 you get the bits you'd expect, so it feels like a 64-bit Float, b) the VM could use 62 bits if it wanted.

Or, to out it a different way, in general putting implementation details in the name is a bad idea, no? The name reflects its semantics (an immutable 64-bit double-precision floating-point value).

> cheers -ben

Eliot (phone)

Ben Coman

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

Eliot Miranda wrote:

>
> Hi Ben,
>
> On Dec 5, 2014, at 5:52 AM, Ben Coman <[hidden email]> wrote:
>
>> Bert Freudenberg wrote:
>>> ------------------------------------------------------------------------
>>> On 26.11.2014, at 23:42, Eliot Miranda <[hidden email] <mailto:[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):
>> AhHA! You let the cat out of the bag then....
>> Sorry, I just had to pull that bike out one more time...
>>
>>>> From: Bert Freudenberg <[hidden email] <mailto:[hidden email]>>
>>>> Subject: Re: Float hierarchy for 64-bit Spur
>>>> Date: 24. November 2014 11:50:34 MEZ
>>>> To: Eliot Miranda <[hidden email] <mailto:[hidden email]>>
>>>>
>>>>
>>>> On 21.11.2014, at 19:08, Eliot Miranda <[hidden email] <mailto:[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
>> (only half tongue-in-cheek) Should SmallFloat61 have been considered?
>
> No! :-). Two reasons, a) if you send at: to a SmallFloat64 you get the bits you'd expect, so it feels like a 64-bit Float, b) the VM could use 62 bits if it wanted.
>
> Or, to out it a different way, in general putting implementation details in the name is a bad idea, no? The name reflects its semantics (an immutable 64-bit double-precision floating-point value).
>
>
>> cheers -ben
>
> Eliot (phone)

Thanks Eliot. Thats what I was fishing to learn.
cheers -ben