7 ms·

Given that the instruction set already has a float to integer conversion it seems likely that the overhead of implementing this would be small and so given the

Given that the instruction set already has a float to integer conversion it seems likely that the overhead of implementing this would be small and so given the performance (and presumably energy) win quoted elsewhere seems like a good move. It would be interesting to know the back story on this: how did the idea feed back from JS implementation teams to ARM. Webkit via Apple or V8 via Google?

olliej 6y ago
Correct, the overhead is minimal - it basically just makes the float->int conversion use a fixed set of rounding and clamping modes, irrespective of what the current mode flags are set to. The problem is JS's double->int conversion was effectively defined as "what wintel does by default", so on arm, ppc, etc you need a follow on branch that checks for the clamping requirements and corrects the result value to what x86 does. Honestly it would not surprise me if the perf gains are due to removing the branch rather than the instruction itself.
- klelatti 6y ago
  Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?
  - freeone3000 6y ago
    The branch always has to be taken if executing JavaScript, because otherwise how would you tell if the value was correct or not? You'd have to calculate it using this method regardless and then compare!
    - olliej 6y ago
      What are you defining as correct?
      - freeone3000 6y ago
        "correct" in this case being consistent with the JavaScript specification.
    - fred256 6y ago
      If you always take a branch, it's not a branch. Or did you mean by "taken" that the branch instruction has to be executed regardless of whether the branch is taken or not?
      - freeone3000 6y ago
        JavaScript JITs always emit this instruction when ToInt32 is required, since checking would be more expensive in user code. And the instruction always used the JS rounding method, since that's cheaper in silicon. I used branch since the parent used "branch".
  - formerly_proven 6y ago
    > Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".
    - brundolf 6y ago
      Seeing as JavaScript was designed and implemented in two weeks, I'm betting this is the answer
      - tekromancr 6y ago
        Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.
        monocasa 6y ago
        Rounding mode was defined then and hasn't changed since though.
        goatlover 6y ago
        Isn’t modern JS backward compatible with 1.1?
        domenicd 6y ago
        Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec. Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g., > In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN. and > In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN. sound like backward-incompatible changes to a JS 1.1 behavior. Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...
- jleahy 6y ago
  Not quite. JS is round towards zero, ie. the same as C. If you look at the x86 instruction set then until SSE2 (when Intel specifically added an extra instruction to achieve this) this was extremely awkward to achieve. x86 always did round-to-nearest as the default. The use of INT_MIN as the overflow value is an x86-ism however, in C the exact value is undefined.
  - deleted 6y ago
    [deleted]
- titzer 6y ago
  > The problem is JS's double->int conversion was effectively defined as "what wintel does by default", No, JavaScript "double to int conversion" (which only happens implicitly in bitwise operations such as |, &, etc) is not like any hardware instruction at all. It is defined to be the selection of the low-order 32-bits of a floating point number as-if it were expanded to its full-width integer representation, dropping any fractional part.

olliej 6y ago

Correct, the overhead is minimal - it basically just makes the float->int conversion use a fixed set of rounding and clamping modes, irrespective of what the current mode flags are set to. The problem is JS's double->int conversion was effectively defined as "what wintel does by default", so on arm, ppc, etc you need a follow on branch that checks for the clamping requirements and corrects the result value to what x86 does. Honestly it would not surprise me if the perf gains are due to removing the branch rather than the instruction itself.

klelatti 6y ago
Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?
- freeone3000 6y ago
  The branch always has to be taken if executing JavaScript, because otherwise how would you tell if the value was correct or not? You'd have to calculate it using this method regardless and then compare!
  - olliej 6y ago
    What are you defining as correct?
    - freeone3000 6y ago
      "correct" in this case being consistent with the JavaScript specification.
  - fred256 6y ago
    If you always take a branch, it's not a branch. Or did you mean by "taken" that the branch instruction has to be executed regardless of whether the branch is taken or not?
    - freeone3000 6y ago
      JavaScript JITs always emit this instruction when ToInt32 is required, since checking would be more expensive in user code. And the instruction always used the JS rounding method, since that's cheaper in silicon. I used branch since the parent used "branch".
- formerly_proven 6y ago
  > Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".
  - brundolf 6y ago
    Seeing as JavaScript was designed and implemented in two weeks, I'm betting this is the answer
    - tekromancr 6y ago
      Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.
      - monocasa 6y ago
        Rounding mode was defined then and hasn't changed since though.
      - goatlover 6y ago
        Isn’t modern JS backward compatible with 1.1?
        domenicd 6y ago
        Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec. Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g., > In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN. and > In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN. sound like backward-incompatible changes to a JS 1.1 behavior. Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...
jleahy 6y ago
Not quite. JS is round towards zero, ie. the same as C. If you look at the x86 instruction set then until SSE2 (when Intel specifically added an extra instruction to achieve this) this was extremely awkward to achieve. x86 always did round-to-nearest as the default. The use of INT_MIN as the overflow value is an x86-ism however, in C the exact value is undefined.
- deleted 6y ago
  [deleted]
titzer 6y ago
> The problem is JS's double->int conversion was effectively defined as "what wintel does by default", No, JavaScript "double to int conversion" (which only happens implicitly in bitwise operations such as |, &, etc) is not like any hardware instruction at all. It is defined to be the selection of the low-order 32-bits of a floating point number as-if it were expanded to its full-width integer representation, dropping any fractional part.