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.'
commits@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 ?
btw, Does that comment need updating... didn't you go with SmallDouble, BoxedDouble?
cheers -ben
Hi Ben,
On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman btc@openinworld.com wrote:
commits@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 heapobjects. 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.
On 26.11.2014, at 23:42, Eliot Miranda eliot.miranda@gmail.com 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 bert@freudenbergs.de Subject: Re: Float hierarchy for 64-bit Spur Date: 24. November 2014 11:50:34 MEZ To: Eliot Miranda eliot.miranda@gmail.com
On 21.11.2014, at 19:08, Eliot Miranda eliot.miranda@gmail.com 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 -
Bert Freudenberg wrote:
On 26.11.2014, at 23:42, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> Subject: Re: Float hierarchy for 64-bit Spur Date: 24. November 2014 11:50:34 MEZ To: Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>
On 21.11.2014, at 19:08, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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
Hi Ben,
On Dec 5, 2014, at 5:52 AM, Ben Coman btc@openInWorld.com wrote:
Bert Freudenberg wrote:
On 26.11.2014, at 23:42, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> Subject: Re: Float hierarchy for 64-bit Spur Date: 24. November 2014 11:50:34 MEZ To: Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>
On 21.11.2014, at 19:08, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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)
Eliot Miranda wrote:
Hi Ben,
On Dec 5, 2014, at 5:52 AM, Ben Coman btc@openInWorld.com wrote:
Bert Freudenberg wrote:
On 26.11.2014, at 23:42, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> Subject: Re: Float hierarchy for 64-bit Spur Date: 24. November 2014 11:50:34 MEZ To: Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>
On 21.11.2014, at 19:08, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> 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
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.
On 28.11.2014, at 02:17, Andres Valloud avalloud@smalltalk.comcastbiz.net 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.
On Thu, Nov 27, 2014 at 5:17 PM, Andres Valloud < avalloud@smalltalk.comcastbiz.net> 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.
vm-dev@lists.squeakfoundation.org
-
Andres Valloud -
Ben Coman -
Bert Freudenberg -
commits＠squeakvm.org -
Eliot Miranda