Kenneth Russell wrote:
On Tue, Mar 26, 2013 at 4:35 PM, David Herman<dher...@mozilla.com> wrote:
[breaking out a new thread since this is orthogonal to the NaN issue]
While the Khronos spec never specified an endianness, TC39 agreed in May 2012
to make the byte order explicitly little-endian in ES6:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html
The de facto reality is that there are essentially no big-endian browsers for
developers to test on. Web content is being invited to introduce byte-order
dependencies. DataView is usually held up as the counter-argument, as if the
*existence* of a safe alternative API means no one will ever misuse the unsafe
one. Even if we don't take into account human nature, Murphy's Law, and the
fact that the web is the world's largest fuzz tester, a wholly rational
developer may often prefer not to use DataView because it's still easier to
read out bytes using [ ] notation instead of DataView methods.
I myself -- possibly the one person in the world who cares most about this
issue! -- accidentally created a buggy app that wouldn't work on a big-endian
system, because I had no way of testing it:
https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b
In summary: we already agreed on TC39 to close this loophole, it's the right
thing to do, and concern about potential performance issues on non-existent
browsers of non-existent systems should not trump portability and correctly
executing existing web content.
I am disappointed that this decision was made without input from both
of the editors of the typed array spec and disagree with the statement
that it is the right thing to do.
First, my apologies to Dave for forgetting the May decision. I was
looking in the wrong place for a record of that decision!
Second, I understand Ken's point of view (old SGI hacker here) but have
to question it on the grounds Dave raises: no one is testing, so there
are very likely to be latent little-endian dependencies in deployed code
today.
So why not codify this? Because it might penalize big-endian systems?
The IP protocols use big-endian byte order (owing to the pre-Intel
big-endian architectures of IMPs and early Internet machines) and so
penalize Intel machines, and we take the hit (and it's small on modern
super-scalar CPUs).
Ken, a couple of questions:
1. Do you know of any big-endian systems with market share that host JS
implementations? It would be great to have a list.
2. Independent of the answer to (1), today's web browsers run on
little-endian systems and that has very likely created a de-facto
standard. If we codify it, we make the small to empty set of big-endian
systems pay a price. Why is this the wrong thing for typed arrays but
the right thing (in reverse! majority-architectures penalized) for the
IP protocol suite?
/be
-Ken
Dave
This was not the plan of record on TC39. The plan was to fix the semantics as
little-endian.
On Mar 25, 2013, at 6:00 PM, Brendan Eich<bren...@mozilla.com> wrote:
Right, thanks for the reminder. It all comes back now, including the "how to write
correct ending-independent typed array code" bit.
/be
On Mar 25, 2013, at 4:33 PM, Kenneth Russell<k...@google.com> wrote:
On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich<bren...@mozilla.com> wrote:
Allen Wirfs-Brock wrote:
On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and floats
a bigger interop issue than NaN cannonicalization? I know this was
discussed in the past, but it doesn't seem to be covered in the latest
Khronos spec. Was there ever a resolution as to whether or not TypedArray
[[Set]] operations need to use a cannonical endian-ness?
Search for "byte order" at
https://www.khronos.org/registry/typedarray/specs/latest/.
I had already search for "endian" with similar results. It says that the
default for DataViews gets/sets that do not specify a byte order is
big-endean. It doesn't say anything (that I can find) about such accesses on
TypedArray gets/sets.
Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE
to match dominant architectures, while DataViews are BE to match packed
serialization use-cases.
Ken, did something get edited out?
No. The typed array views (everything except DataView) have used the
host machine's endianness from day one by design -- although the typed
array spec does not state this explicitly. If desired, text can be
added to the specification to this effect. Any change in this behavior
will destroy the performance of APIs like WebGL and Web Audio on
big-endian architectures.
Correctly written code works identically on big-endian and
little-endian architectures. See
http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a
detailed description of the usage of the APIs.
DataView, which is designed for input/output, operates on data with a
specified endianness.
-Ken
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
