Float hierarchy for 64-bit Spur

>
> On Fri, Nov 21, 2014 at 8:01 AM, Tobias Pape <[hidden email]> wrote:
>>
>> On 21.11.2014, at 15:30, Bert Freudenberg <[hidden email]> wrote:
>>
>> >
>> > On 21.11.2014, at 13:53, Tobias Pape <[hidden email]> wrote:
>> >
>> >> On 21.11.2014, at 13:44, Bert Freudenberg <[hidden email]> wrote:
>> >>> 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.
>> >
>> > Good point. Do you have a suggestion for names reflecting that?
>>
>>
>> First: I think it is possible to have both SmallInteger/Large*Integer as well
>> as all Float stuff combined such that we only have
>>         - Integer
>>         - Float
>> and the VM has to deal with internal stuff, ie representing small enough numbers
>> tagged and larger ones as boxed (which could, for example, mean to not be able
>> to access the boxed values from the image side…).
>>   However, this is “Zukunftsmusik” or “ungelegte Eier” (Things to come or not even
>> considered).
>>
> I don't find this compelling for reasons I've expressed earlier in the thread.  Personally I think the VM shouldn't be in the business of hiding much.  There are advantages to it hiding the machinery that connects contexts to stack frames and methods to machine code because that allows us to use the same system with very different VMs and that's hugely advantageous (see the Stack VM and SqueakJS for examples).  But that doesn't for example hide contexts, it just optimizes teir use.

>>
>> Second: I think the small/large stuff is semantically correct, because that is what
>> it is, whether immediate or not:
>>         - Integer: SmallInteger, LargeInteger
>>         - Float: SmallFloat, LargeFloat
>> I don't think there's confusion about the single=float thing when you don't have
>> the name double somewhere.
>
> Agreed.
>
>>  
>>   Rationale against immediate in the name: Immediate/Non-Immediate is a means to
>> an end, which is, speed for small or “few” things: ints, floats, chars. When you
>> make something different immediate — just for fun: very short ascii strings like
>> "hello" stored as 0x000068656C6C6F04 and 04 being the tag — you shouldn't name it
>> ImmediateString but TinyString, because thats why it is there, an optimization
>> for very tiny things.
>>
> Agreed.  But note that I will /not/ be pursuing things like immediate strings.  IMO this is a bad idea.  Whereas there are really compelling arguments for immediate integers, characters and floats, there aren't for strings or symbols.  

> Most strings and most symbols are longer than 7 bytes
>
> (ByteSymbol allInstances collect: [:ea| ea size]) sum asFloat / ByteSymbol allInstances size 17.905990063082676
> (ByteString allInstances collect: [:ea| ea size]) sum asFloat / ByteString allInstances size 192.12565808504485
>
> So choosing this representation doesn't save much space and loses time because the more complex mixed representation is involved in many operations (e.g. replaceFrom:to:with:startingAt: is now way more complex).
>
> In fact, I'm thinking that a 2 bit tag is probably better.  AFAIA, since I implemented 64-bit VisualWorks with a 3 bit tag no one has added any new immediate types.  Points don't have the necessary dynamic frequency and indeed points with floats may be very common in newer UI architectures.  Making nil, true and false immediates doesn't have much benefit either; they're unique values, and unique addresses work just as well as immediates.  Essentially expanding the number of tagged types, and especially making the tagged type organization non-uniform (see e.g. Eliot Moss's VMs where nil, true, false have one organization, character has a another and SmallInteger another one still) makes the decode bloat, which slows down message send.  So I think for the moment I'll go with a 2 bit tag, giving us an even larger range for SmallDouble and SmallInteger, and keep the simple representation:
>
> immediates
> [62 bit value][2 bit tag]
> non-immediates
> [64 bit pointer (least 3 bits 0)] -> [8 bit slot count][2 gc bits][22 bit hash][3 gc bits][5 bit format][2 flag bits][22 bit class index]
> --
> best,
> Eliot

> Hi Tobias,
>
> On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <[hidden email]> wrote:
> Hi Eliot
>
> On 21.11.2014, at 19:06, Eliot Miranda <[hidden email]> wrote:
> >
> > Hi Tobias,
> >
> > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <[hidden email]> wrote:
> >
> > > Hi,
> > >
> > > On 21.11.2014, at 13:44, Bert Freudenberg <[hidden email]> wrote:
> > >
> > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) <
> > > [hidden email]> wrote:
> > > >
> > > >> Quoting Bert Freudenberg <[hidden email]>:
> > > >>>
> > > >>> 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?  

>  
> To be abstract, or to be concrete, that is the question.
>
> Coming back to Eliot's proposal:
>
> > modify class Float to be an abstract class, and add two subclasses, BoxedFloat and SmallFloat, such that existing boxed instances of Float outside the SmallFloat range will become instances of BoxedFloat and instances within that range will be replaced by references to the relevant SmallFloat.
> > [...]
> > An alternative [...] is to add a superclass, e.g. LimitedPrecisionReal, move most of the methods into it, and keep Float as Float, and add SmallFloat as a subclass of LimitedPrecisionReal.
>
>
> Float
>   |
>   +------- BoxedFloat
>   |
>   +------- SmallFloat
>
>
> LimitedPrecisionReal
>   |
>   +------- Float
>   |
>   +------- SmallFloat
>
>
> The actual question was if the class named "Float" (as used in expressions like "Float pi") should be concrete or abstract.
>
> I strongly agree with Eliot's assessment that making Float the abstract superclass is best. What we name the two concrete subclasses is bikeshedding, and I trust Eliot to pick something not too unreasonable.
>

> I had to reverse-engineer it because Dan could not remember (only later
> we got a printout of the VM's 8086 assembly source code). It's optimized
> for a software implementation with the mantissa on a 16-bit word boundary.
> Not sure why the exponent's sign bit is in the LSB though. But 16 bits of
> exponent, can you imagine the range? Luckily there were no insanely large
> instances in the snapshot. They get converted to modern floats when parsing
> the original object space dump:
>
>     wordsAsFloat: function() {
>         // layout of NoteTaker Floats (from MSB):
>         // 15 bits exponent in two's complement without bias, 1 bit sign
>         // 32 bits mantissa including its highest bit (which is implicit