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

Ben Coman btc at openInWorld.com
Fri Nov 21 07:23:04 UTC 2014


Ben Coman wrote:
> 
> Eliot Miranda wrote:
>>  
>> Hi Ben,
>>
>> On Nov 20, 2014, at 8:42 PM, Ben Coman <btc at openInWorld.com> wrote:
>>
>>> Eliot Miranda wrote:
>>>> On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc at openinworld.com 
>>>> <mailto:btc at openinworld.com>> wrote:
>>>>    Eliot Miranda wrote:
>>>>        Hi All,
>>>>            64-bit Spur can usefully provide an immediate float, a
>>>>        61-bit subset of the ieee double precision float.     I 
>>>> wonder if class SmallDouble would be more intention revealing?
>>>>    In practice 61 bits will be "more than enough"(tm) for anyone. But I
>>>>    can envisage in a business environment environment software needing
>>>>    to comply with (sometimes irrelevant) feature checklists, with one
>>>>    of those likely being full 64 bit compliant IEEE Doubles.  Can we
>>>>    have such a class, to which 61 bit floats are auto-promoted as 
>>>> required?
>>>> Just as SmallInteger is seamless with the large integers, so 
>>>> SmallFloat is seamless with boxed Float.  The SmallFloat 
>>>> representation is used where ever possible, since it is faster both 
>>>> to decode (no memory fetch) and to encode (no allocation).  But 
>>>> operations overflow into the boxed representation if outside the 
>>>> SmallFloat range.
>>> (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and 
>>> LargeFloat would align better with the Integer hierarchy.)
>>>
>>> So I understand that immediate types will overflow to boxes types :)
>>>
>>> To try to be more clear, integers don't have a well defined 
>>> size/format.  It varies with architecture word size.  So SmallInteger 
>>> and LargeInteger are reasonable descriptions.  But floats have a well 
>>> defined format defined by IEEE. Since you are pivoting around the 
>>> IEEE Double format (you define it as "61-bit subset of the ieee 
>>> double precision float"), rather than generic SmallFloat and 
>>> LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off 
>>> track. Its not a big deal).
>>
>> Ah, I like this.  Thanks.

a random thought on implementation of LargeDouble...
is it worth considering a performance versus space tradeoff...
rather than boxing LargeDouble so that access through a pointer reduces 
performance(?), could the value be stored in a second 64bits adjacent to 
the first? Or does being 128 bits in total complicate things too much?

cheers -ben


More information about the Squeak-dev mailing list