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

[Eliot Miranda]

Hi Tobias,

On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <Das.Linux at gmx.de> wrote:

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

yes, alas it is all about tradeoffs :-).  But that's great.  The more
varieties the merrier.


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

Hmmm, somewhere there's got to be a discrimination between SmallIntegers
and other objects, right?

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


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