[Vm-dev] float word order
Eliot Miranda
eliot.miranda at gmail.com
Sun Apr 19 14:57:20 UTC 2009
On Sun, Apr 19, 2009 at 6:43 AM, Bryce Kampjes <bryce at kampjes.demon.co.uk>wrote:
>
> On Sat, 2009-04-18 at 18:15 -0700, Eliot Miranda wrote:
> > Hi All,
> >
> >
> > I see that Float 32-bit word order is big-endian (PowerPC) on all
> > platforms. This is a pain for performance and a pain for code
> > generation in Cog. For example using SSE2 instructions it is trivial
> > to swizzle a PowerPC-layout Float into an xmm register using the
> > PSHUFD SSE2 instruction but tediously verbose to swizzle on write,
> > because one has to swizzle to an xmm register which is hence
> > destructive, which means three instructions (shuffle, write,
> > unshuffle) just to write a Float result. Yes, ok 2 extra instructions
> > is small potatoes, but they're still starch. So I wonder what would
> > the impact be of maintaining Floats in platform order? There are a
> > number of possible solutions.
> >
> >
> > 1. Floats are always in platform order and swizzled on image load when
> > moving from little-endian to big-endian or vice verce. Image code
> > must be rewritten to take the platform's endianness into account.
> > (requires an image rewrite)
> >
> >
> > 2. As for 1 but the image is isolated from the change by providing
> > two primitives, primitiveFloatAt and primitiveFloatAtPut which are
> > implemented with selectors at: basicAt: at:put: and basicAt:put: on
> > Float. These primitives map index 1 onto the most significant word
> > and index 2 onto the least significant word. (requires no image
> > rewrite, but does require a file-in of the four implementations)
>
> I'd like to see Floats stored in native format too. Don't forget about
> the 32 bit floats in Float arrays.
Tell me more :) Are these in some funky order, or are they just IEEE single
precision in platform order?
>
>
> Bryce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090419/e9272a25/attachment.htm
More information about the Vm-dev
mailing list