On 28 March 2013 23:01, David Herman wrote:
> On Mar 27, 2013, at 6:51 AM, Andreas Rossberg wrote:
>
>> There actually are (third-party) projects
>> with ports of V8 and/or Chromium to big endian architectures.
>
> It would be helpful to have more information about what these platforms and
> pro
On 28 March 2013 21:42, Mark S. Miller wrote:
> "prohibitively" depends on your tolerance. Modern machines can usually do
> register-to-register byte order reversal rather speedily. Which big endian
> machines do you have in mind?
For WebGL, which expects native endianness on its end, you'll have
On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd wrote:
> One could also argue that people using typed arrays to alias and munge
> individual values should be using DataView instead. If it performs poorly,
> that can hopefully be addressed in the JS runtimes (the way it's specified
> doesn't seem to pr
One could also argue that people using typed arrays to alias and munge
individual values should be using DataView instead. If it performs poorly,
that can hopefully be addressed in the JS runtimes (the way it's specified
doesn't seem to prevent it from being efficient).
-kg
On Sun, Mar 31, 2013 a
(Apologies for breaking threading -- subscribed too late to have
original message to reply to.)
David Herman wrote:
On Mar 27, 2013, at 6:51 AM, Andreas Rossberg https://mail.mozilla.org/listinfo/es-discuss>> wrote:
>/ There actually are (third-party) projects
/>/ with ports of V8 and/or Chr
On Mar 27, 2013, at 6:51 AM, Andreas Rossberg wrote:
> There actually are (third-party) projects
> with ports of V8 and/or Chromium to big endian architectures.
It would be helpful to have more information about what these platforms and
projects are.
> WebGL
> code should not break or become p
"prohibitively" depends on your tolerance. Modern machines can usually do
register-to-register byte order reversal rather speedily. Which big endian
machines do you have in mind?
On Wed, Mar 27, 2013 at 6:51 AM, Andreas Rossberg wrote:
> On 27 March 2013 00:35, David Herman wrote:
> > [breaking
On Mar 27, 2013, at 7:53 PM, Jussi Kalliokoski
wrote:
>
> Given that we can't guarantee that the bit pattern will remain unchanged the
> spec should mandate normalizing to the non-signalling NaN.
>
> --Oliver
>
> It's not trivially exploitable, at least not in SM or V8. I modified the
> exa
Jussi Kalliokoski wrote:
I think standardizing whatever V8 is doing with NaN right now seems
like the best option.
No, we cannot preserve NaN "payloads" in other engines that nanbox or
pwnage ensues.
The spec leaves this as an underspecified interop hazard and that seems
to be the best opti
On 27 March 2013 00:35, David Herman 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/pipermai
On Tue, Mar 26, 2013 at 10:29 AM, Oliver Hunt wrote:
>
> On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski <
> jussi.kallioko...@gmail.com> wrote:
>
> That's just because ES has had no notion of bits for floating points
> before. Other than that, ES NaN works like IEEE NaN, e.g.
>
> 0/0 === NaN // f
Old SGI-hacker-me is on board with spec'ing as-is. Thanks,
/be
On Mar 26, 2013, at 7:02 PM, Kenneth Russell wrote:
> Dmitry, thank you for prototyping and benchmarking this. There should
> be no question that a slowdown of 25% is too high a cost to pay.
>
> Allen's analysis earlier in the thre
Dmitry, thank you for prototyping and benchmarking this. There should
be no question that a slowdown of 25% is too high a cost to pay.
Allen's analysis earlier in the thread indicates that no spec changes
are necessary in order to allow multiple bit patterns to be used when
storing NaNs into Float
On 03/26/2013 08:48 AM, Sam Tobin-Hochstadt wrote:
> While I agree with you on the larger point (and this issue reoccurs
> with proxies), the actual problem here is that [[DefineProperty]]
> should just do nothing on immutable data. The idea of mutating
> immutable data as long as its the same val
On Tue, Mar 26, 2013 at 4:35 PM, David Herman 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
[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
I would like to add some perf numbers to this discussion, if I may.
I have implemented a quick patch for V8 that implements NaN normalization
on Float64Array store. V8 does not use NaN boxing, so from implementation
perspective NaN normalization is not required by V8.
In my test, the perf penalty
On Mar 26, 2013, at 1:29 AM, Oliver Hunt wrote:
>
> Ok, I'll try to go over this again, because for whatever reason it doesn't
> appear to stick:
>
> If you have a double-typed array, and access a member:
> typedArray[0]
>
> Then in ES it is a double that can be one of these values: +Infiniti
Oliver Hunt wrote:
Given that we can't guarantee that the bit pattern will remain
unchanged the spec should mandate normalizing to the non-signalling NaN.
This is where Kenneth parts company, arguing for safety (no pwnage, no
ability to forge a NaN in engines that nanbox) but against
interope
No mystery here: SpiderMonkey canonicalizes all NaN bit patterns to
0x7FF8LL.
/be
Brandon Benvie wrote:
On 3/26/2013 10:39 AM, Brandon Benvie wrote:
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable
On 3/26/2013 10:39 AM, Brandon Benvie wrote:
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value,
so that example is
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value,
so that example is invalid.
It becomes observable on the read en
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value,
so that example is invalid.
It becomes observable on the read end by doing:
float64array[0] = shouldBeImm
On Tue, Mar 26, 2013 at 3:54 AM, Mark S. Miller wrote:
> // The [[DefineProperty]] algorithm is allowed to overwrite
> shouldBeImmutable.foo
While I agree with you on the larger point (and this issue reoccurs
with proxies), the actual problem here is that [[DefineProperty]]
should just do no
ozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Andreas Rossberg
Sent: Tuesday, March 26, 2013 6:40 AM
To: Oliver Hunt
Cc: Mark S. Miller; Brendan Eich; es-discuss
Subject: Re: Observability of NaN distinctions — is this a concern?
I'm with Dave and Oliver. Worrying about the
I'm with Dave and Oliver. Worrying about the performance cost of NaN
normalisation has a strong smell of premature micro optimisation. The
one branch per float store, whose cost should be amortised by branch
prediction when frequent, seems very unlikely to be measurable
compared to everything else
On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski
wrote:
> That's just because ES has had no notion of bits for floating points before.
> Other than that, ES NaN works like IEEE NaN, e.g.
>
> 0/0 === NaN // false
> isNaN(0/0) // true
That's true in any language - comparing to NaN is almost alwa
On Tue, Mar 26, 2013 at 9:54 AM, Mark S. Miller wrote:
>
>
>
> On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski <
> jussi.kallioko...@gmail.com> wrote:
>
>>
>> On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt wrote:
>>
>>>
>>> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock
>>> wrote:
>>>
>>> >
>>
On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
>
> On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt wrote:
>
>>
>> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock
>> wrote:
>>
>> >
>> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
>> >
>> >> Right, thanks
On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt wrote:
>
> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock
> wrote:
>
> >
> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
> >
> >> Right, thanks for the reminder. It all comes back now, including the
> "how to write correct ending-independent type
On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock wrote:
>
> On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
>
>> Right, thanks for the reminder. It all comes back now, including the "how to
>> write correct ending-independent typed array code" bit.
>
> Ok, so looping back to my earlier observ
* Kenneth Russell wrote:
>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.
That seems to be ca
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
> Right, thanks for the reminder. It all comes back now, including the "how to
> write correct ending-independent typed array code" bit.
Ok, so looping back to my earlier observation. It sounds like endian-ness can
be observed by writing into a
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 wrote:
> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich wrote:
>> Allen Wirfs-Brock wrote:
>>>
>>> On Mar 25, 2
On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich 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 cannonicali
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 cov
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 lates
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
On Mar 25, 2013, at 2:40 PM, Brendan Eich wrote:
> Kenneth Russell wrote:
>>> > For interop, JS requires cross-browser (VM) NaN canonicalization to avoid
>>> > observably different results on different browsers.
>>
>> As long as NaN values loaded from Float32Array and Float64Array obey
>> ES6'
On Mon, Mar 25, 2013 at 2:40 PM, Brendan Eich wrote:
> Kenneth Russell wrote:
>>>
>>> > For interop, JS requires cross-browser (VM) NaN canonicalization to
>>> > avoid
>>> > observably different results on different browsers.
>>
>>
>> As long as NaN values loaded from Float32Array and Float64Arr
Kenneth Russell wrote:
> For interop, JS requires cross-browser (VM) NaN canonicalization to avoid
> observably different results on different browsers.
As long as NaN values loaded from Float32Array and Float64Array obey
ES6's semantics, such as returning true from isNaN(), then it should
no
On Fri, Mar 22, 2013 at 10:34 PM, David Herman wrote:
> On Mar 22, 2013, at 7:47 PM, Brendan Eich wrote:
>
>> Kenneth Russell wrote:
>>> I hope that the ES6 integration of typed arrays will not require
>>> normalization of NaNs on write, even if other specification changes
>>> need to be made to
On Fri, Mar 22, 2013 at 7:47 PM, Brendan Eich wrote:
> Kenneth Russell wrote:
>>
>> I hope that the ES6 integration of typed arrays will not require
>> normalization of NaNs on write, even if other specification changes
>> need to be made to avoid requiring it.
>
>
> What other specification chang
On Mar 20, 2013, at 2:47 PM, Allen Wirfs-Brock wrote:
> Here is the exact language that is in the current ES6 draft for storing a
> Number into a buffer as a Float64 (rawValue is the value that gets stored
> into the buffer):
>
> Set rawValue to the 8 bytes that are the IEEE-868-2005 binary64
On Mar 20, 2013, at 1:57 PM, Allen Wirfs-Brock wrote:
> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
>
>> That normalization on read is is my case 1 above — it is necessary _for that
>> implementation_. A conformant implementation could use a different strategy
>> which does not normalize on
On Mar 22, 2013, at 7:47 PM, Brendan Eich wrote:
> Kenneth Russell wrote:
>> I hope that the ES6 integration of typed arrays will not require
>> normalization of NaNs on write, even if other specification changes
>> need to be made to avoid requiring it.
>
> What other specification changes?
Ke
Kenneth Russell wrote:
I hope that the ES6 integration of typed arrays will not require
normalization of NaNs on write, even if other specification changes
need to be made to avoid requiring it.
What other specification changes?
JITs use nan-boxing
(http://wingolog.org/archives/2011/05/18/val
On Mar 20, 2013, at 2:38 PM, Kenneth Russell wrote:
>>
>
> The typed array specification in its original form deliberately
> avoided specifying normalization of NaNs upon writes to Float32Array
> and Float64Array. Doing so has no practical value and only imposes a
> performance hit, which is una
On Wed, Mar 20, 2013 at 2:24 PM, Kevin Reid wrote:
> On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock
> wrote:
>>
>> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
>>>
>>> That normalization on read is is my case 1 above — it is necessary _for
>>> that implementation_. A conformant implementati
On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock wrote:
> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
That normalization on read is is my case 1 above — it is necessary _for
>> that implementation_. A conformant implementation could use a different
>> strategy which does not normalize on Fl
On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
>
> That normalization on read is is my case 1 above — it is necessary _for that
> implementation_. A conformant implementation could use a different strategy
> which does not normalize on Float64 read, and this would be unobservable, so
> the sp
On Wed, Mar 20, 2013 at 12:56 PM, Allen Wirfs-Brock
wrote:
>
> If you're specifically talking about reading/writing TypedArray elements
> (really ArrayBuffers) you have to take into account the possibility that
> you can have different types overlaying the same buffer storage.
>
Yes, that was my
On 3/20/2013 12:56 PM, Allen Wirfs-Brock wrote:
If you're specifically talking about reading/writing TypedArray
elements (really ArrayBuffers) you have to take into account the
possibility that you can have different types overlaying the same
buffer storage. Hence a NaN bit pattern might be wr
On Mar 20, 2013, at 12:34 PM, Kevin Reid wrote:
> On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
> wrote:
> On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
>
> > Depending on what you mean by “ECMAScript code”, this may be false given
> > the Typed Arrays extension, which allows direct a
On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
wrote:
> On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
>
> > Depending on what you mean by “ECMAScript code”, this may be false given
> the Typed Arrays extension, which allows direct access to the bit-patterns
> of float values (the Typed Arra
Le 20/03/2013 19:08, Jeff Walden a écrit :
I don't see what can reasonably be done about it, without effectively mandating
attempting NaN-substitution whenever the value to set might be NaN.
+1. I think Safari needs to be fixed.
Stuffing info in NaNs sounds superfluous. JS has objects, arrays,
On Mar 20, 2013, at 11:08 AM, Jeff Walden wrote:
> Negation on at least some x86-ish systems also produces another kind of NaN,
> because the trivial negation implementation is a sign-bit flip.
>
> This strikes me as similar to the endianness concerns of typed arrays, except
> probably far less
Negation on at least some x86-ish systems also produces another kind of NaN,
because the trivial negation implementation is a sign-bit flip.
This strikes me as similar to the endianness concerns of typed arrays, except
probably far less harmful in practice. I don't see what can reasonably be do
58 matches
Mail list logo
