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

Eliot Miranda eliot.miranda at gmail.com
Fri Nov 21 18:06:29 UTC 2014


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.


  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.


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


thanks
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141121/9f05809d/attachment-0001.htm


More information about the Vm-dev mailing list