3 ms·

Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. Even the modest 32-bit integer multiplication is tri

• pcwalton 14y ago
  > Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. No, in asm.js, numbers are not always floats. There is a type system that can classify numbers into integers. Native 64 bit integers are being worked on as an extension.
  • niggler 14y ago
    32 bit integers can be represented exactly in a Number but not 64 bit integers. And the typed array system provides Int32Array and Uint32Array but no 64-bit Downvoters: which part of the statement is factually incorrect? Read the ES3 and ES5 specs
    • pcwalton 14y ago
      Implementing 64-bit integers on top of JavaScript is going to happen. It's far less effort to implement 64-bit integers than to adopt Native Client, and JavaScript needs 64-bit ints anyway—the Node community has been asking for it for a long time, for example.
• jlongster 14y ago
  Just like pcwalton said, you can trick js engines to do real 32-bit arithmetic. (x|0 + y|0)|0 tells the engine that it's 32-bits all the way through, and it optimizes it appropriately and never touches floats. 64-bits is a problem, yes, but again like pcwalton said, it is being worked on for post ES6 era. Obviously, if the Unreal Engine is working, it's not necessarily critical & a show-stopper, but it is needed for certain things. Edit: Math.imul is needed because the number can become large enough to where the engine converts it to a double, and then converts it back and you lose precision (I think that's how it works). It's the only arithmetic that needs fixing.
  • niggler 14y ago
    "(x|0 + y|0)|0 tells the engine that it's 32-bits all the way through" You conveniently skipped the complaint: "Even the modest 32-bit integer multiplication is tricky (you only have 52-53 bits of mantissa)"
  • jlongster 14y ago
    @niggler I did at first but I added a quick edit after I posted. It's not a hard thing to fix.
    • niggler 14y ago
      "It's not a hard thing to fix." But then you get back into the game of asking browser vendors to make changes, which was one of the original selling points of asm.js (that browser vendors didn't have to make changes).
      • jlongster 14y ago
        Sure, it's unfortunate, but it's one obscure edge case that they can implement instantly. They are still pushed to implement asm.js anyway, so that just comes with it. If they don't, things like BananaBread do still run, so it's not required, it's just an obscure edge case.
      • BrendanEich 14y ago
        JS is changing, ES6 is coming. Browser vendors want changes and are on board. They're also under competitive pressure. But in what scenario is the much greater work to add Pepper and PNaCl support going to prevail? You have to assume JS dies or freezes, and there's exogenous pressure for something new. Instead, we see demand for JS to evolve (Mozilla serves this, we aren't just ginning it up, believe me!). So browser vendors would have to do two big jobs: tend the web standards and evolve them, and put in a new native code runtime alongside. That is simply not going to happen outside of Google, which can afford endless impossible-to-standardize boondoggles. It is both uneconomic, and technically inferior to a more minimal evolutionary path-finding solution. /be