> Which is odd, because you don't expect to see JavaScript so close to the bare metal.
This seems to ignore all the work done on server-side javascript with projects such as node.js and deno, as well as the fact that cloud service providers such as AWS have been developing their own ARM-based servers.
Not surprising to me to see CPU instructions being added for widely used use cases. Basically, a CPU instruction set maker's job is to perform clustering of the tasks that the CPUs do and accelerate commonly used tasks. If people do a lot of AES, the instruction set maker adds AES extensions. If people do a lot of CRC, they add CRC instructions. If people convert doubles to integers all day in a very JS specific way, then that's the instruction they add.
With reduced instruction sets, though, the idea is to provide common subparts and make them fast rather than dedicated instructions. While it's not odd to see dedicated instructions in CPUs in general, it's jarring to see if you're familiar with ARM chips from back when they had 25 instructions total.
Yeah that's how RISC vs CISC is taught in class, I've heard that same thing. I think it's an outdated paradigm though, if it's not been wrong all along. A CISC chip can still officially support instructions, but deprecate them and implement them very slowly in microcode, as is done with some x86 instructions. And a RISC chip manufacturer might just have used this phrase as a marketing line because designing RISC chips is easier than starting with a monster that has tons of instructions, and they needed some catchy phrase to market their alternative. They then get into the gradual process of making their customers happier one by one by adding special, mostly cold, silicon targeted for special workflows, like in this instance.
Ultimately, the instruction set isn't that relevant anyways, what's more relevant is how the microcode can handle speculative execution for common workflows. There's a great podcast/interview from the x86 specification author: https://www.youtube.com/watch?v=Nb2tebYAaOA
Can you name any other instructions with the name of a programming language in the actual instruction name?
No? Then it seems way more specific than the other examples you listed. So specific that it’s only applicable to a single language and that language is in the instruction name. That’s surprising, like finding an instruction called “python GIL release”.
Not necessarily programming languages (in similar vain as what est31 said) but cryptography has made its way into instructions, see SHA1RNDS4, SHA1NEXTE, SHA1MSG1 and more. They are not general cryptographic primitives but specific instructions for computing a specific cryptographic hash, just because SHA became popular. Also has SHA in it's name :)
You could say that these are language-agnostic, and indeed they are, but in a certain way they are more specific than the JavaScript operation, because the JavaScript operation is likely used in many different algorithms. I'd argue that from the point of view of a chip manufacturer, the difference matters only little. Both are tasks that the CPUs do often and thus cost energy. By implementing them natively, the CPU manufacturer reduces the cost of those workflows for their clients.
More importantly, the customers of the cpu vendors use benchmarks to evaluate potential chip suppliers, and Js benchmarks are near the top of the list for ARM now. Everyone from the OS vendor to the compiler authors to ARM itself are looking at the same operations, so instructions like this get requested and added.
There are also funny xaflag, axflag instructions in armv8 specifically to speed up x86 emulation on arm64. I believe they were added at the request of the msft emulator team.
In addition to what the sibling comments said, note that "Python GIL release" is a very high level concept and how the GIL is implemented can change over time. It interacts with how the OS implements locking. FJCVTZS on the other hand is a (mostly) pure function with well defined inputs and outputs, and will likely be useful for Javascript implementations for a long time. Will JS be around in 10 years? Very likely. So ARM adds an instruction for it.
The people at ARM have likely put a lot of thought behind this, trying to find the places where they, as instruction set vendor, can help making JS workflows easier.
And btw, I'm pretty sure that if python has some equally low hanging fruit to make execution faster, and python enjoys equally large use, ARM will likely add an instruction for it as well.
The Javascript spec decided to standardize float operations and (in part) opted for whatever x86 did. ARM had different floating point profiles so ARM processors had to emulate in software intel's operations. Thus ARM decided to simply implement intel's operation as an instruction and called it by the relevant use case.
Off the top of my head, and ignoring the Java bytecode instructions added at one point, no. I can however think of quite a lot of crypto related instructions, and many CPU and MMU features aimed at very specific language features such as garbage collection.
Well if you go far enough back, it was not usual to find special allowance for programming language constructs (like procedure linkage that supported display, useful for languages like Pascal with nested procedures etc).
The reason you don't find this is that all "modern" processors designed since ~ 1980 are machines to run ... C as the vast majority (up until ~ Java) of all software on desktops and below were written in C. This also has implications for security as catching things like out of bound access or integer overflow isn't part of C so doing it comes with an explicit cost even when it's cheap in hardware.
It doesn't surprise me because we are supposed to expect commonly used programming languages to receive optimizations. If we didn't follow this logic there would be no reason to optimize C. Instead each processor company would optimize for their own proprietary language and expect everyone to use the proprietary language for high performance needs.
> No it doesn’t, it’s still surprising to see a CPU instruction added specifically to cater for such a high level language like JS.
It surprises you personally, but if you think about it it's easy to understand that widespread interpreters that use a specific number crunching primitive implented in software can and do benefit from significant performance improvements if they offload that to the hardware.
You only need to browse through the list of opcodes supported by modern processors to notice a countless list of similar cases of instructions being added to support even higher-leve operations.
I mean, are you aware that even Intel added instructions for signal processing, graphics, and even support for hash algorithms?
And you're surprised by a floating point rounding operation?
Just because a language is used on servers / at scale / in enterprise, doesn't make it any closer to the metal. I mean, look at Python, Java, or Ruby: All used on servers for "serious" applications, but certainly not any sort of "bare metal" languages still.
> Which is odd, because you don't expect to see JavaScript so close to the bare metal.
This seems to ignore all the work done on server-side javascript with projects such as node.js and deno, as well as the fact that cloud service providers such as AWS have been developing their own ARM-based servers.