[Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

Tobias Pape Das.Linux at gmx.de
Fri Nov 21 18:52:49 UTC 2014


Hi Eliot

On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi Tobias,
> 
> On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> > Hi,
> >
> > On 21.11.2014, at 13:44, Bert Freudenberg <bert at freudenbergs.de> wrote:
> >
> > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) <
> > juanlists at jvuletich.org> wrote:
> > >
> > >> Quoting Bert Freudenberg <bert at freudenbergs.de>:
> > >>>
> > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete
> > subclasses (*). Names do mean something. (**)
> > >>>
> > >>> You're right about the FloatArray confusion. However, note that the
> > IEEE standard calls it single and double. It's only C using "float" to mean
> > "single precision".
> > >>>
> > >>> I'd name the abstract superclass Float, for readability, and the
> > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I
> > don't see the need for having a deep LimitedPrecisionReal - Float -
> > BoxedDouble/ImmediateDouble deep hierarchy now.
> > >>>
> > >>> If we ever add single-precision floats, we should name them
> > BoxedSingle and ImmediateSingle. At that point we might want a Single
> > superclass and a LimitedPrecisionReal supersuperclass, but we can cross
> > that bridge when we get there.
> > >>>
> > >>> - Bert -
> > >>>
> > >>> (*) Since we're not going to see the class names often, we could even
> > spell it out as BoxedDoublePrecisionFloat and
> > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation
> > to the abstract Float very clear.
> > >>>
> > >>> (**) We could also try to make the names googleable. I was surprised
> > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it.
> > Maybe there are two better words?
> > >>
> > >> I very much agree with Bert. But I'd suggest SmallDouble instead of
> > ImmediateDouble for consistency with SmallInteger.
> > >
> > > Then it would have to be LargeDouble for consistency with LargeInteger,
> > too. Which I don't find compelling.
> > >
> > > Also, with the 64 bit format we get many more immediate objects. There
> > already are immediate integers and characters, floats will be the third,
> > there could be more, like immediate points. For those, the small/large
> > distinction does not make sense.
> > >
> > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead
> > of "small" use "immediate":
> > >
> > >       Float - BoxedFloat - ImmediateFloat
> > >
> > >       A Float is either a BoxedFloat or an ImmediateFloat, depending on
> > the magnitude of its exponent.
> >
> > I don't like the idea of putting a VM/Storage detail into the Class name.
> > The running system itself does not care about whether Floats or Integers
> > are
> > boxed or immediate.
> >
> 
> I disagree.  I think at least Smalltalk-80 has a philosophy of lifting as
> much out of the VM into the system, and hiding it from clients via
> encapsulation.  So unlike many other VMs the compiler is in the system, the
> system explicitly separates SmallInteger, LargePositiveInteger and
> LargeNegativeInteger and implements large integer arithmetic with Smalltalk
> code that uses SmallIntegers.  Note that the primitives are an optional
> extra optimization that the VM does not need to implement.  So for me it is
> in keeping with the current system to use BoxedFloat and SmallFloat or
> BoxedDouble and SmallDouble.
> 
> This lifting things up provides us with an extremely malleable system.
> Pushing things down into the VM does the opposite.
> 

I can understand. It is however a tradeoff between abstraction and malleability.
I'd rather see everything done in Smalltalk. Yet primitives not exposing its
innards.

  I think I just can't have the cake and have it, too.

> 
>   For example in RSqueakVM (aka SPy) there is no immediate
> > Integer whatsoever. Yes, tagged ints are read during image startup but they
> > aren't subsequently represented as immediates or tagged ints after that.
> >
> 
> Well because it's implemented above RPython I guess it is using Python's
> bignum code directly.  That's fine but its a bit of a cheat.

I was talking of SmallInts here. There is no bignum code involved.
On the RPython side, SmallIntegers are just objects that have a field 
that is not accessible from Smalltalk but keeps a machine-word integer. 

> 
> 
> >
> >   Just as input, in the Racket language and other Schemes,
> > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum
> > and for floats they have flonums and "extflonums" (80bit).
> >
> > Best
> >         -Tobias
> 
> 


More information about the Squeak-dev mailing list