Otherwise you end up using too many instructions to achieve simple things. Sometimes different semantics can be much slower; you can see this when emulating architecture A on architecture B, and why Apple's switchable memory-ordering semantics are absolute genius.
Also, this is why GPUs and DSPs exist.
> Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences.
> Armv8.3-A adds instructions that convert a double-precision floating-point number to a signed 32-bit integer with round towards zero. Where the integer result is outside the range of a signed 32-bit integer (DP float supports integer precision up to 53 bits), the value stored as the result is the integer conversion modulo 2^32, taking the same sign as the input float.
The semantics of numbers in JavaScript behave in a specific way. Since we are talking about numbers, it hardly gets more low-level and thus it makes good sense to design ALU operations targeting common numerical operations.
The floating operation themselves are done in fixed point with large registers.
This instructions tells the cpu to bypass part of the circuit. The javascript thing is just branding to make devs aware of the application of the instructions.
Ironically, this actually gives more control of the hardware rather than increase abstraction.
Once the decision is made to use microprogrammed control, the cost to expand an instruction set is very small; only a few more words of control store. Since the sizes of control memories are often powers of 2, sometimes the instruction set can be made more complex at no extra hardware cost by expanding the microprogram to completely fill the control memory. [1]
[1] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...
It should exist because the alternative would be C style undefined behavior in Javascript. Remember how everyone says that C is fast because undefined behavior means that C does not have to encode the semantics of a particular architecture to be fast and therefore is the fastest on every architecture. Things like bitshifting have subtle differences between architectures and therefore have to be undefined behavior to be fast everywhere.
In Javascript it's the opposite. It cannot have any undefined behavior because it is untrusted code that has to be executed inside a sandbox and not infect the user's computer. But people wanted Javascript to be faster so they simply took the behavior of the fastest and most common architecture that Javascript was used on and just put them into the Javascript specs. That architecture was x86 and to our surprise: ARM is not x86. This means if you want fast Javascript on ARM, it has to adopt x86 rounding semantics. Compared to the unbounded costs of undefined behavior it's a microscopic price to pay.
so in a sense i agree you, but i only think that because i think javascript shouldn’t exist!