W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] Endianness of typed arrays

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 28 Mar 2012 16:42:49 +1300
Message-ID: <CAOp6jLaMZ09Ah2-kmXw+oAo1EvTwHAnELFr7VjLXHUaEdhiwuQ@mail.gmail.com>
On Wed, Mar 28, 2012 at 3:43 PM, Kenneth Russell <kbr at google.com> wrote:

> Production browsers already implement typed arrays with their current
> semantics. It is not possible to change them and have WebGL continue
> to function. I will go so far as to say that the semantics will not be
> changed.
>

What's the problem? A big-endian machine could interpret WebGL typed arrays
as little-endian.

Experience has shown that the moment an artificial performance
> barrier is imposed, it becomes impossible to build certain kinds of
> programs. I consider it unacceptable to prevent developers from
> achieving their goals.
>

Can you elaborate on the performance issues you're concerned about? I'm
assuming all future big-endian architectures will have efficient hardware
support for byte-swapping (ARM does).

The current environment (negligible market share for big-endian machines
among Web users and developers, and no prospect of that changing) means Web
developers, and hence Web pages, will depend on machines being
little-endian wherever that is exposed in the Web platform. Web browsers on
big-endian machines will have to pretend to be little-endian as far as Web
pages can observe. At this point there is no alternative. The only question
is whether this is documented in the spec or not.

Rob
-- 
?You have heard that it was said, ?Love your neighbor and hate your enemy.?
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
Received on Tuesday, 27 March 2012 20:42:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC