4 ms·

I always thought it was insane that the CPUs had instructions specific to a particular application in a particular operating system embedded in them. I think th

I always thought it was insane that the CPUs had instructions specific to a particular application in a particular operating system embedded in them. I think the close we get to the metal, the more abstract and general purpose things should get. For example, things like "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" should not exist at all.

gameswithgo 6y ago
if there is computation people are doing a lot, and a hardware instruction can make it faster, i will take it. so in a sense i agree you, but i only think that because i think javascript shouldn’t exist!
henrikeh 6y ago
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/developer/ip-products/processors/b... > 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.
boibombeiro 6y ago
The hardware overhead to implement this particular instructions is likely very small. 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.
CalChris 6y ago
The reason CISC became so complicated was that microcode stores were getting larger. 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] The reason for an instruction like that Javascript one are similar: reports of Moore's Law demise are greatly exaggerated and DRAMs are getting bigger. Yes, these instructions may offend your sensibilities but the transistors are available and there are important benchmarks for important customers. Chips+ISAs aren't abelian groups, especially ARM chips+ISAs. RISC-V has extensions which promise to be the wild west all over again. [1] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...
als0 6y ago
I think the instruction is just misnamed. It definitely shouldn't have the word Javascript in it. It's just a different floating point format. As others have noted, it's not more complicated than any other floating point instruction.
pjc50 6y ago
This sounds nice and clean and theoretic, but in practice you get better results by matching the design to the workload. Computers aren't new, we know what the workload might be. Javascript is a couple of decades old. The challenge is getting compilers to use it - which is much easier with non-AOT languages, where you can update the compiler for existing code without involving the developer. 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.
secondcoming 6y ago
It sure is an interesting instruction to implement. I can only assume that someone, somewhere, has graphs of commonly executed code sequences and concluded that there was merit in supporting Javascript's requirements in the ISA.
imtringued 6y ago
>For example, things like "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" should not exist at all. 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.

gameswithgo 6y ago

if there is computation people are doing a lot, and a hardware instruction can make it faster, i will take it. so in a sense i agree you, but i only think that because i think javascript shouldn’t exist!

henrikeh 6y ago

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/developer/ip-products/processors/b... > 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.

boibombeiro 6y ago

The hardware overhead to implement this particular instructions is likely very small. 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.

CalChris 6y ago

The reason CISC became so complicated was that microcode stores were getting larger. 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] The reason for an instruction like that Javascript one are similar: reports of Moore's Law demise are greatly exaggerated and DRAMs are getting bigger. Yes, these instructions may offend your sensibilities but the transistors are available and there are important benchmarks for important customers. Chips+ISAs aren't abelian groups, especially ARM chips+ISAs. RISC-V has extensions which promise to be the wild west all over again. [1] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...

als0 6y ago

I think the instruction is just misnamed. It definitely shouldn't have the word Javascript in it. It's just a different floating point format. As others have noted, it's not more complicated than any other floating point instruction.

pjc50 6y ago

This sounds nice and clean and theoretic, but in practice you get better results by matching the design to the workload. Computers aren't new, we know what the workload might be. Javascript is a couple of decades old. The challenge is getting compilers to use it - which is much easier with non-AOT languages, where you can update the compiler for existing code without involving the developer. 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.

secondcoming 6y ago

It sure is an interesting instruction to implement. I can only assume that someone, somewhere, has graphs of commonly executed code sequences and concluded that there was merit in supporting Javascript's requirements in the ISA.

imtringued 6y ago

>For example, things like "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" should not exist at all. 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.