At 10:41 AM 9/2/98, Dan Ingalls wrote:
>P.S.  For various reasons that have been discussed on this list before
>(notably sound and image processing), it is likely that we will soon add
>some Float array operations to Squeak.  It may be that we will do this by
>using a general API, but we have not yet sorted out all the portability vs
>VM size issues.
>

At 4:32 PM 6/12/98, Andreas Raab wrote:
>Hans-Martin,
>
>> I would propose to go further than that and change the format of Floats
>> as well, to make all float-containing objects be usable from the
>> platform without special macros.
>
>I agree. There are only a few locations where the order of Floats is
>important and those could be changed to use selectors like #highWord and
>#lowWord instead of #basicAt:
>
>> However, this opens another, more difficult, question:
>> Since doubles on some platforms have to be 8-byte aligned, objects (at
>> least those potentially containing doubles) should probably be aligned
>> on 8-byte minus 4.
>
>The alternative would be using single precision floats in the FloatArrays.
>Actually, I was investigating this since the storage overhead of double
>precision floats outweighs the improved precision in a number of
>applications (say in 3D graphics where you have literally millions of
>them).
>
>Bye,
>  Andreas


Dan--

I hope that the Float arrays will be single precision.  Beyond 8-byte
alignment and extra storage issues, there is a compelling performance issue
as well.  The PPC supports a pipelined multiply-accumulate instruction for
single precision numbers.  When methods for image/signal processing
applications are translated to C it would be nice for the C-compiler to be
able to make use of the mult-accum hardware.

Has there ever be discussion of making Squeak use intrinsic 30-bit
SmallFloats like it uses SmallInteger?  Are both object pointer tag bits
already used?

--Maurice


---------------------------------------------------------------------------
  Maurice Rabb    773.281.6003    Stono Technologies, LLC    Chicago, USA