[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 Vm-dev
mailing list