22 ms·

ARM chips have an instruction with JavaScript in the name

406 points by kdeldycke 6y ago

mhh__ 6y ago
Unless I misread the current arm docs, I don't think this is still present in the ISA as of 2020? The whole RISC/CISC thing is long dead anyway, so I don't really mind having something like this on my CPU. Bring on the mill (I don't think it'll set the world on fire if they ever make it to real silicon but it's truly different)
- kanox 6y ago
  Arm v8 is the "current" 64-bit version of the ISA and you almost certainly have it inside your phone. You might have a version older than v8.3.
- jbirer 6y ago
  I think you are thinking of the old Java-optimizing instructions on the older ARM processors.
  - saagarjha 6y ago
    Those never really took off…
- alain94040 6y ago
  To understand RISC, ignore the acronym it stands for, instead just think fixed-instruction, load-store architecture. That's what RISC really means today. No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.
  - userbinator 6y ago
    ...and even ARM breaks instructions into uops, just like x86.
    - mhh__ 6y ago
      Of course it does. The level of abstraction required for modern pipelining and OOo scheduling is still beneath ARM. I'm not that familiar with the details of arm on paper but it's not that low level by research standards.
  - dragontamer 6y ago
    > No variable-length instructions AESE / AESMC (AES Encode, AES Mix-columns) are an instruction pair in modern ARM chips in which the pair runs as a singular fused macro-op. That is to say, a modern ARM chip will see "AESE / AESMC", and then fuse the two instructions and execute them simultaneously for performance reasons. Almost every "AESE" encode instruction must be followed up with AESMC (mix columns), so this leads to a significant performance increase for ARM AES instructions.
  - elygre 6y ago
    Someone once explained it like “not a reduced set, but a set of reduced instructions”. Not r(is)c, but (ri)sc. Pretty much what you say, I just liked the way of describing it.
    - FullyFunctional 6y ago
      It seems to me people are ignoring that the C stands for Complexity. What's reduced is Complexity of the instruction set, not the size of it (or even the instructions themselves). In the context of the coinage of the term, they almost certainly could have called it "microcode-free ISA", but it wouldn't have sounded as cool.
      - mavhc 6y ago
        Doesn't the C stand for Computer?
        FullyFunctional 6y ago
        Oops I'm wrong about the name but not about the spirit. This is the original paper: https://dl.acm.org/doi/pdf/10.1145/641914.641917 https://dl.acm.org/doi/pdf/10.1145/641914.641917
      - andromeduck 6y ago
        Is ARM even microcode free these days?
        arthurcolle 6y ago
        I dont think so
  - Joker_vD 6y ago
    What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?
    - sharpneli 6y ago
      Fixed width instructions allow trivial parallel instruction decoding. With variable length instructions one must decode a previous one to figure out where the next one will start.
      - scottlamb 6y ago
        > With variable length instructions one must decode a previous one to figure out where the next one will start. People said the same thing about text encodings. Then UTF-8 came along. Has anyone applied the same idea to instruction encoding?
        Someone 6y ago
        That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction). It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.
        scottlamb 6y ago
        That doesn't sound so bad to me, in comparison to fixed-size instructions. One bit in each byte gone to have the most common instructions take one byte instead of four. I can imagine that allowing much denser code overall. Or it could be one bit out of every pair of bytes, to support 2-, 4-, and 6-byte instructions. I don't know much about ARM Thumb-2, except that it does 2- or 4-byte instructions, so clearly someone thought this much was a good idea. Instruction encodings are below my usual abstraction layer; I'm just speculating...
  - wolfgke 6y ago
    > think fixed-instruction, l[...]. That's what RISC really means today. > No variable-length instructions. So, ARM is not a RISC instruction set, because T32 (Thumb-2) instruction can be 2 or 4 bytes long. Similarly, RISC-V has variable-length instructions for extensibility. See p. 8ff of https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... (section "Expanded Instruction-Length Encoding").
- ramshorns 6y ago
  What does it mean for the RISC/CISC thing to be dead? The distinction between them is more blurred than it used to be?
  - dragontamer 6y ago
    RISC / CISC was basically IBM-marketing speak for "our processors are better", and never was defined in a precise manner. The marketing is dead, but the legend lives on years later. IBM's CPU-advancements of pipelining, out-of-order execution, etc. etc. were all implemented into Intel's chips throughout the 90s. Whatever a RISC-machine did, Intel proved that the "CISC" architecture could follow suite. ------ From a technical perspective: all modern chips follow the same strategy. They are superscalar, deeply-pipelined, deeply branch predicted, micro-op / macro-op fused "emulated" machines using Tomasulo's algorithm across a far larger "reorder buffer register" set which is completely independent of the architectural specification. (aka: out-of-order execution). Ex: Intel Skylake has 180 64-bit reorder buffer registers (despite having 16 architectural registers). ARM A72 has 128-ROB registers (depsite having 32-architectural registers). The "true number" of registers of any CPU is independent of the instruction set.
    - FullyFunctional 6y ago
      Since RISC wasn't coined by IBM (but by Patterson and Ditzel) this is just plain nonsense. RISC was and is a philosophy that's basically about not adding transistors or complexity that doesn't help performance and accepting that we have to move some of that complexity to software instead. Why wasn't it obvious previously? A few things had to happen: compilers had to evolve to be sophisticated enough, mindsets had to adapt to trusting these tools to do a good enough job (I actually know several who in the 80' still insisted on assembler on the 390), and finally, VLSI had to evolve to the point where you could fit an entire RISC on a die. The last bit was a quantum leap as you couldn't do this with a "CISC" and the penalty for going off-chip was significant (and has only grown).
  - FullyFunctional 6y ago
    Not even remotely. Nothing in the RISC philosophy says anything about pure data-path ALU operations. In fact this instruction is pretty banal compared to many other FP instructions.
barumi 6y ago
FTA: > 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.
- orf 6y ago
  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 does totally makes sense though, given the importance of JS and it’s common use in mobiles.
  - barumi 6y ago
    > 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?
    - moritzwarhier 6y ago
      Considering that JS is JIT-compiled and doesn't have an integer type, this is not suprising to me at all.. (but still interesting)
  - imtringued 6y ago
    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.
kanox 6y ago
My guess is that this is what JIT people asked for.
- amelius 6y ago
  Don't sufficiently advanced compilers infer what the real type of a variable is, in the most important cases?
  - chrisseaton 6y ago
    Many important cases are polymorphic so have to be able to handle both.
  - robocat 6y ago
    First comment on question: “The JavaScript engine has to do this operation (which is called ToInt32 in the spec) whenver you apply a bitwise operator to a number and at various other times (unless the engine has been able to maintain the number as an integer as an optimization, but in many cases it cannot). – T.J. Crowder” Edit: From https://www.ecma-international.org/ecma-262/5.1/#sec-9.5 https://www.ecma-international.org/ecma-262/5.1/#sec-9.5 9.5 ToInt32: (Signed 32 Bit Integer) The abstract operation ToInt32 converts its argument to one of 2 integer values in the range −2³¹ through 2³¹−1, inclusive. This abstract operation functions as follows: Let number be the result of calling ToNumber on the input argument. If number is NaN, +0, −0, +∞, or −∞, return +0. Let posInt be sign(number) * floor(abs(number)). Let int32bit be posInt modulo 2³²; that is, a finite integer value k of Number type with positive sign and less than 2³² in magnitude such that the mathematical difference of posInt and k is mathematically an integer multiple of 2³². If int32bit is greater than or equal to 2³¹, return int32bit − 2³², otherwise return int32bit. NOTE Given the above definition of ToInt32: The ToInt32 abstract operation is idempotent: if applied to a result that it produced, the second application leaves that value unchanged. ToInt32(ToUint32(x)) is equal to ToInt32(x) for all values of x. (It is to preserve this latter property that +∞ and −∞ are mapped to +0.) ToInt32 maps −0 to +0.
    - domenicd 6y ago
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
nom 6y ago
So it was easier to add an instruction in silicon to cater for an ill-designed programming language, than to change the language itself? I mean, if float-to-integer performance is so critical, why was this not fixed a long time ago in the language? What am I missing?
- deleted 6y ago
  [deleted]
- offtop5 6y ago
  Consider Node JS is a top server side language, and arm for data centers is coming ( to the extent it's not already here), this makes sense. Technically someone can just make a better VM engine for JavaScript to execute inside of, but whatever I guess they decided this would be easier.
  - dtech 6y ago
    I'd say JS on the mobile ARM devices is 10.000x more common, and thus important, than the NodeJS on ARM servers.
    - offtop5 6y ago
      Wait. Do you mean JS inside of browsers themselves ? Or JS running in another manner
    - hajile 6y ago
      Amazon has already rolled out their own ARM servers at a very cheap price. A lot of well-funded companies are headed in that same direction. Adding this instruction encourages those designs too (very good from a licensing standpoint).
- untog 6y ago
  > What am I missing? I guess the incredibly long tail of JavaScript deployments. You could change the language today and it would take years for it to percolate down to all the deployments out there. By comparison a silicon change requires zero code changes and is entirely backwards compatible. Plus there's a pretty simple marketing argument: "buy our CPU, it makes commonly-encountered workloads faster", vs "buy our CPU, when everyone upgrades the platform they use it'll be faster"
marcusarmstrong 6y ago
If anybody else was curious, it appears that the performance win of use of this instruction looks to be about 1-2% in general javascript workloads: https://bugs.webkit.org/show_bug.cgi?id=184023#c24 https://bugs.webkit.org/show_bug.cgi?id=184023#c24
- nichch 6y ago
  Is that significant enough to justify the instruction?
  - lstamour 6y ago
    It is if it also increases battery life by a similar amount ;-)
  - secondcoming 6y ago
    Nothing justifies the prolonging of Javascript torture.
    - Joker_vD 6y ago
      Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?
      - wnoise 6y ago
        It's not like other languages are well-adapted to that either. That's a hard target to code for.
        goatlover 6y ago
        Why couldn’t Haskell compilers make good use of that?
nabla9 6y ago
SPARC processors have tagged add and subtract instructions to help dynamic languages.
- goatinaboat 6y ago
  IBM has hardware acceleration for XML processing, of all things, so there is plenty of precedent for this. https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/perf/src/tpc/db2z_ibmzaap.html https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0...
- FullyFunctional 6y ago
  ... which were removed in SPARCv8 (64-bit) because nobody used them.
rhacker 6y ago
It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.
- tachyonbeam 6y ago
  Are you saying you'd like to have specific int32, int64, float32, float64 types?
  - jjuhl 6y ago
    Strong typing and static typing - yes please.
    - afiori 6y ago
      In terms of adding types to deeply dynamic languages I think Julia had the best approach: sub-typing and union types. It has the advantage that it is possible to give a reasonable type to most functions without a rewrite (even if the types would be terribly long to accommodate the weak underlying type system)
  - rhacker 6y ago
    Yes this specifically.
- kevincox 6y ago
  With WebAssembly that day is nearing. However it is certainly many years out.
- jayd16 6y ago
  You could split the difference and go C# or Java and use one of their web stacks.
- qball 6y ago
  >But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development. I think that day might be sooner than anyone thinks- Chromium is dominant enough now that their including Dart as a first-class language (or more likely, a successor to Dart) will likely be a viable strategy soon. Of course, the wildcard is Apple, but ultimately Dart can compile down to JS- being able to write in a far superior language that natively runs on 80% of the market and transpiles to the rest is suddenly much more of a winning proposition.
klelatti 6y ago
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?
chubot 6y ago
Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irrational-exuberance/ https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irra... We need to incorporate JavaScript and Python workloads into our evaluations. There are already standard benchmark suites for JavaScript performance in the browser, and we can include applications written in node.js (server-side JavaScript), Python web servers, and more. This is where cycles are being spent today, and we need evaluation that matches modern workloads. For example, we should care less if a proposed mobile chip or compiler optimization slows down SPEC, and care more if it speeds up Python or JavaScript!
- FullyFunctional 6y ago
  Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and has failed before (ie. Jazelle, picoJava, etc).
  - sterlind 6y ago
    maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.
    - FullyFunctional 6y ago
      WASM is _designed_ to be easily jitted, without the expensive machinery we had to put in place to do this for x86, so the whole point is not require a new architecture. Because of this I find WASM to be the best direction yet for a "universal ISA" as it's very feasible to translate to most strange new radical architecture (like EDGE, Prodigy, etc). (Introducing a new ISA is almost impossible due to the cost of porting the world. RISC-V might be the last to succeed).
smt1 6y ago
Remember, don't think too hard about this stuff. It's better to meditate. You can apparently just telepathically learn this stuff by activating your paraterial lobe which can take 2-nary infos about learn to think about it as more generalized cognitive processes properly. Sharing = caring. I think it's best understood under a generalized ethnographic "utterance" aka linguistic and cultural problem in say a first order generalized theory of computing or combinatorics. aka the discrete log encoding::decode problem or the more ancient wisdom not passing down quick enough problem. When 2 group of static people of different cultures that some static group can just (lua) = implicitly define stuff very hard (combinatorical optimization) = branch and bound, it's better to remember than coding=calculate can be just thought as just a data structure problem (do a one time pad) in a generalized calculation in a automorphism and using techniques found in that abstract syntax tree that JavaScript can gradually typed more safely using TypeScript which Microsoft "already" gradually feed a generalized search engine (Google) knows so they can just Wikipedia (autocode the "Wisdom of the Crowds") it. I'd understand it by understanding first principles from logic and congitive sciences and applied software engineering. Software defined dynamic by necessity requires regularization to be very secure cryptographically to be ever exist in the first place. But remember you can think about it anything another way. This is basically doing a reinterpret_cast in classical first order C++. I personally think about it best as myself as a lexically scoped optimizing compiler using words compiled in some interior language to do a 1:1 mapping in Visual Studio to static analysis where my "utterances" can really apparently convince people that pattern matching stuff can really understood various matching techniques to recognize that these are just the same patterns. Basic elementary physics and elementary internet-networking things to do figure out some paradoxes: 1. why aren't people focusing on general energy scavenging in principle? Apparently other people are. But it requires change of focus in many respects. Basically you can on a computer on software do it safely, but in the physical world, you may accidentally be doing very non-sensical things like imagining that you can just do an inversion of gravity. 2. remember that bias exists, but history suggests that bias can be thought many different ways. your experiences bias you, but sometimes humans beings need to think automatically in new adductive reasoning inferential systems in safety. That can only be done to affect the real world in computer simulation. This can add to human knowledge though. Deductive and inductive and coinductive can be performed over arbitrary domains in whatever order theoretic ways. 3. remember these are just analogies. They can condition your mind, but could also let your brain think more clearly. 4. for example implicit::ego::bias (abc) problem. 5. everyone who knows signal processing knows singular "poles" as 0 can be patched up by more modern stable manifold theory but only people who understand that boundaries are just arbitrary of linear spaces. Remember than in the cultural sense of philosophy you can uw "hard" stuff once you understand traditionally thought of random [0,1] as boolean as more rich simplexes in the newer norm space [-1,1] which modern probability theory can be applied to. It creates a generalized system of norms of measurement of classical informational theory space. Sorry for being so cryptic but recall that you could understand that shannon for example "accidentally" created the information by creating information and commutation theory by autodualizing math and a implicit association of a simple easy to read 1 page document that created a "digital bit". Equated as entropy. You could understand say hibert who let his "school" understand inf dimensional spaces. I'll just point out a few free hugs in unicode spectrum (see https://home.unicode.org/emoji/emoji-frequency/ https://home.unicode.org/emoji/emoji-frequency/). I just understand to look at it using free glue guns but people will have to discover the right modulation schemes themselves in discrete logarithms but it may require say, for example, doing 3 simultaneous generalizations to combine 2 y-combinators of information theoretic boolean bits could be remodulated into L-R folded "cultural" to use experience to debias past implicit bias and use + forward thinking bias to auto create quasi-well ordered programs that computer science people have already created. let's just say I know by experience I know these things: 1. the www was originally created for people to collaborate over long distances to communicate more easily with clarity by being disconnected 2. social media was created for people to communicate as "new" ways but things facebook and twitter got too polluted by disinformation 3. telecomm systems eventually went from very messy error connecting codes modems and progressed to broadband by easing collaboration yet censorship still exists 4. search engine systems consuming more and more information to help locate stuff, but things like google get new bits of interformation to associations in their own internal db 5. it was at one time very hard to write international software but the invention of unicode helped people get access to the internet for the first time 6. the open/free source software like github and cultural practices like code reviews, allowed software developers for people around teams and corporations in remote areas to collaborate easily 7. computing devices like phones and smarter free computer languages allowed safer gradually and shifting codes of conduct to allow more open collaboration 8. the creation of cryptographic two session protocols allowed two parties security agree to securely exchange two exchange metadata together and work together 9. in applied software engineering, the creation of distributed version control systems like git and linux allowed mass adoption of free software 10. so these days in the software world you can just code software just by "coding" by pasting in semantic meaningful this is compositional software. 11. the productivity improvements in computer science has been enormous so that most people can save on energy both in hardware and software and refocus on more important stuff
offbynull 6y ago
Anyone else remember the ARM Jazelle DBX extension? I wonder if they'll end up dumping this in this the same way. I don't remember very many phones supporting DBX, but IIRC the ones that did seemed to run J2ME apps much smoother.
- saagarjha 6y ago
  This one is at least documented and in use by major browsers, so I doubt it will go away anytime soon.
- masklinn 6y ago
  It's quite different though, Jazelle literally implemented java bytecode in hardware. These instructions "merely" performs a float -> int conversion with JS semantics, such that implementations don't have to reimplement those semantics in software on ARM. The JS semantics probably match x86 so x86 gets an "unfair" edge and this is a way for ARM to improve their position.
- repiret 6y ago
  It takes a lot more silicon to implement Jazelle than a single well-tailored ALU instruction. Moreover, while the market for "JVM on small Arms" never really took off, the market for "JavaScript on Arms of all sizes" is flourishing and has been for at least a dozen years.
Animats 6y ago
Nice. Also useful is a set of integer operations that raise an exception on overflow.
barnacled 6y ago
It strikes me as ironic that an architecture that used to pride itself on being RISC and simple is heading in the same direction as intel-levels of masses of specialist instructions. I don't mean this as a criticism, I just wonder if this is really the optimum direction for a practical ISA
- anaganisk 6y ago
  May be as the time increases the threshold for being a RISC increases as the tech advances?
- kmeisthax 6y ago
  Ironically this instruction only exists because JavaScript accidentally inherited an Intel quirk in it's double-to-int conversion. This instruction should be "Floating Point Intel Convert" not "Floating Point Javascript Convert", but w/e, trademark laws and all that. In practice the instruction made code a few percent faster, primarily because it allowed dropping a few branches at the end of every JavaScript int conversion on ARM. IMO, ARM has always been at the "edge" of RISC (at least until AArch64 threw out all of it's quirks) and the exception proves the rule here. Instructions like this exist specifically because they accelerate execution time, rather than for assembler programmer convenience. That's the same underlying reason why RISC had such an advantage over CISC before micro-op decoders and register renaming became a thing. It's not so much that "having less instructions is better", but that things like memory operands or repeat prefixes or what have you primarily act as programmer convenience at the expense of code efficiency. Stuff like FJCVTZS is used by compiled code to gain a measurable speed benefit, ergo it stays in.
dboreham 6y ago
All cpu have instructions with nsa in the name. Well not in the name, but added at their behest at some point in history.
bitwize 6y ago
The dream of the Lisp machine is long dead. Our computers are now JavaScript machines.
lxe 6y ago
A good follow up to "HTML5 Hardware Accelerator Card" from yesterday: https://news.ycombinator.com/item?id=24806089 https://news.ycombinator.com/item?id=24806089

406 points by kdeldycke 6y ago

Unless I misread the current arm docs, I don't think this is still present in the ISA as of 2020? The whole RISC/CISC thing is long dead anyway, so I don't really mind having something like this on my CPU. Bring on the mill (I don't think it'll set the world on fire if they ever make it to real silicon but it's truly different)

kanox 6y ago
Arm v8 is the "current" 64-bit version of the ISA and you almost certainly have it inside your phone. You might have a version older than v8.3.
jbirer 6y ago
I think you are thinking of the old Java-optimizing instructions on the older ARM processors.
- saagarjha 6y ago
  Those never really took off…
alain94040 6y ago
To understand RISC, ignore the acronym it stands for, instead just think fixed-instruction, load-store architecture. That's what RISC really means today. No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.
- userbinator 6y ago
  ...and even ARM breaks instructions into uops, just like x86.
  - mhh__ 6y ago
    Of course it does. The level of abstraction required for modern pipelining and OOo scheduling is still beneath ARM. I'm not that familiar with the details of arm on paper but it's not that low level by research standards.
- dragontamer 6y ago
  > No variable-length instructions AESE / AESMC (AES Encode, AES Mix-columns) are an instruction pair in modern ARM chips in which the pair runs as a singular fused macro-op. That is to say, a modern ARM chip will see "AESE / AESMC", and then fuse the two instructions and execute them simultaneously for performance reasons. Almost every "AESE" encode instruction must be followed up with AESMC (mix columns), so this leads to a significant performance increase for ARM AES instructions.
- elygre 6y ago
  Someone once explained it like “not a reduced set, but a set of reduced instructions”. Not r(is)c, but (ri)sc. Pretty much what you say, I just liked the way of describing it.
  - FullyFunctional 6y ago
    It seems to me people are ignoring that the C stands for Complexity. What's reduced is Complexity of the instruction set, not the size of it (or even the instructions themselves). In the context of the coinage of the term, they almost certainly could have called it "microcode-free ISA", but it wouldn't have sounded as cool.
    - mavhc 6y ago
      Doesn't the C stand for Computer?
      - FullyFunctional 6y ago
        Oops I'm wrong about the name but not about the spirit. This is the original paper: https://dl.acm.org/doi/pdf/10.1145/641914.641917 https://dl.acm.org/doi/pdf/10.1145/641914.641917
    - andromeduck 6y ago
      Is ARM even microcode free these days?
      - arthurcolle 6y ago
        I dont think so
- Joker_vD 6y ago
  What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?
  - sharpneli 6y ago
    Fixed width instructions allow trivial parallel instruction decoding. With variable length instructions one must decode a previous one to figure out where the next one will start.
    - scottlamb 6y ago
      > With variable length instructions one must decode a previous one to figure out where the next one will start. People said the same thing about text encodings. Then UTF-8 came along. Has anyone applied the same idea to instruction encoding?
      - Someone 6y ago
        That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction). It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.
        scottlamb 6y ago
        That doesn't sound so bad to me, in comparison to fixed-size instructions. One bit in each byte gone to have the most common instructions take one byte instead of four. I can imagine that allowing much denser code overall. Or it could be one bit out of every pair of bytes, to support 2-, 4-, and 6-byte instructions. I don't know much about ARM Thumb-2, except that it does 2- or 4-byte instructions, so clearly someone thought this much was a good idea. Instruction encodings are below my usual abstraction layer; I'm just speculating...
- wolfgke 6y ago
  > think fixed-instruction, l[...]. That's what RISC really means today. > No variable-length instructions. So, ARM is not a RISC instruction set, because T32 (Thumb-2) instruction can be 2 or 4 bytes long. Similarly, RISC-V has variable-length instructions for extensibility. See p. 8ff of https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... (section "Expanded Instruction-Length Encoding").
ramshorns 6y ago
What does it mean for the RISC/CISC thing to be dead? The distinction between them is more blurred than it used to be?
- dragontamer 6y ago
  RISC / CISC was basically IBM-marketing speak for "our processors are better", and never was defined in a precise manner. The marketing is dead, but the legend lives on years later. IBM's CPU-advancements of pipelining, out-of-order execution, etc. etc. were all implemented into Intel's chips throughout the 90s. Whatever a RISC-machine did, Intel proved that the "CISC" architecture could follow suite. ------ From a technical perspective: all modern chips follow the same strategy. They are superscalar, deeply-pipelined, deeply branch predicted, micro-op / macro-op fused "emulated" machines using Tomasulo's algorithm across a far larger "reorder buffer register" set which is completely independent of the architectural specification. (aka: out-of-order execution). Ex: Intel Skylake has 180 64-bit reorder buffer registers (despite having 16 architectural registers). ARM A72 has 128-ROB registers (depsite having 32-architectural registers). The "true number" of registers of any CPU is independent of the instruction set.
  - FullyFunctional 6y ago
    Since RISC wasn't coined by IBM (but by Patterson and Ditzel) this is just plain nonsense. RISC was and is a philosophy that's basically about not adding transistors or complexity that doesn't help performance and accepting that we have to move some of that complexity to software instead. Why wasn't it obvious previously? A few things had to happen: compilers had to evolve to be sophisticated enough, mindsets had to adapt to trusting these tools to do a good enough job (I actually know several who in the 80' still insisted on assembler on the 390), and finally, VLSI had to evolve to the point where you could fit an entire RISC on a die. The last bit was a quantum leap as you couldn't do this with a "CISC" and the penalty for going off-chip was significant (and has only grown).
- FullyFunctional 6y ago
  Not even remotely. Nothing in the RISC philosophy says anything about pure data-path ALU operations. In fact this instruction is pretty banal compared to many other FP instructions.

barumi 6y ago

FTA: > 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.

orf 6y ago
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 does totally makes sense though, given the importance of JS and it’s common use in mobiles.
- barumi 6y ago
  > 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?
  - moritzwarhier 6y ago
    Considering that JS is JIT-compiled and doesn't have an integer type, this is not suprising to me at all.. (but still interesting)
- imtringued 6y ago
  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.

kanox 6y ago

My guess is that this is what JIT people asked for.

amelius 6y ago
Don't sufficiently advanced compilers infer what the real type of a variable is, in the most important cases?
- chrisseaton 6y ago
  Many important cases are polymorphic so have to be able to handle both.
- robocat 6y ago
  First comment on question: “The JavaScript engine has to do this operation (which is called ToInt32 in the spec) whenver you apply a bitwise operator to a number and at various other times (unless the engine has been able to maintain the number as an integer as an optimization, but in many cases it cannot). – T.J. Crowder” Edit: From https://www.ecma-international.org/ecma-262/5.1/#sec-9.5 https://www.ecma-international.org/ecma-262/5.1/#sec-9.5 9.5 ToInt32: (Signed 32 Bit Integer) The abstract operation ToInt32 converts its argument to one of 2 integer values in the range −2³¹ through 2³¹−1, inclusive. This abstract operation functions as follows: Let number be the result of calling ToNumber on the input argument. If number is NaN, +0, −0, +∞, or −∞, return +0. Let posInt be sign(number) * floor(abs(number)). Let int32bit be posInt modulo 2³²; that is, a finite integer value k of Number type with positive sign and less than 2³² in magnitude such that the mathematical difference of posInt and k is mathematically an integer multiple of 2³². If int32bit is greater than or equal to 2³¹, return int32bit − 2³², otherwise return int32bit. NOTE Given the above definition of ToInt32: The ToInt32 abstract operation is idempotent: if applied to a result that it produced, the second application leaves that value unchanged. ToInt32(ToUint32(x)) is equal to ToInt32(x) for all values of x. (It is to preserve this latter property that +∞ and −∞ are mapped to +0.) ToInt32 maps −0 to +0.
  - domenicd 6y ago

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

nom 6y ago

So it was easier to add an instruction in silicon to cater for an ill-designed programming language, than to change the language itself? I mean, if float-to-integer performance is so critical, why was this not fixed a long time ago in the language? What am I missing?

deleted 6y ago
[deleted]
offtop5 6y ago
Consider Node JS is a top server side language, and arm for data centers is coming ( to the extent it's not already here), this makes sense. Technically someone can just make a better VM engine for JavaScript to execute inside of, but whatever I guess they decided this would be easier.
- dtech 6y ago
  I'd say JS on the mobile ARM devices is 10.000x more common, and thus important, than the NodeJS on ARM servers.
  - offtop5 6y ago
    Wait. Do you mean JS inside of browsers themselves ? Or JS running in another manner
  - hajile 6y ago
    Amazon has already rolled out their own ARM servers at a very cheap price. A lot of well-funded companies are headed in that same direction. Adding this instruction encourages those designs too (very good from a licensing standpoint).
untog 6y ago
> What am I missing? I guess the incredibly long tail of JavaScript deployments. You could change the language today and it would take years for it to percolate down to all the deployments out there. By comparison a silicon change requires zero code changes and is entirely backwards compatible. Plus there's a pretty simple marketing argument: "buy our CPU, it makes commonly-encountered workloads faster", vs "buy our CPU, when everyone upgrades the platform they use it'll be faster"

marcusarmstrong 6y ago

If anybody else was curious, it appears that the performance win of use of this instruction looks to be about 1-2% in general javascript workloads: https://bugs.webkit.org/show_bug.cgi?id=184023#c24 https://bugs.webkit.org/show_bug.cgi?id=184023#c24

nichch 6y ago
Is that significant enough to justify the instruction?
- lstamour 6y ago
  It is if it also increases battery life by a similar amount ;-)
- secondcoming 6y ago
  Nothing justifies the prolonging of Javascript torture.
  - Joker_vD 6y ago
    Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?
    - wnoise 6y ago
      It's not like other languages are well-adapted to that either. That's a hard target to code for.
      - goatlover 6y ago
        Why couldn’t Haskell compilers make good use of that?

nabla9 6y ago

SPARC processors have tagged add and subtract instructions to help dynamic languages.

goatinaboat 6y ago
IBM has hardware acceleration for XML processing, of all things, so there is plenty of precedent for this. https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/perf/src/tpc/db2z_ibmzaap.html https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0...
FullyFunctional 6y ago
... which were removed in SPARCv8 (64-bit) because nobody used them.

rhacker 6y ago

It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.

tachyonbeam 6y ago
Are you saying you'd like to have specific int32, int64, float32, float64 types?
- jjuhl 6y ago
  Strong typing and static typing - yes please.
  - afiori 6y ago
    In terms of adding types to deeply dynamic languages I think Julia had the best approach: sub-typing and union types. It has the advantage that it is possible to give a reasonable type to most functions without a rewrite (even if the types would be terribly long to accommodate the weak underlying type system)
- rhacker 6y ago
  Yes this specifically.
kevincox 6y ago
With WebAssembly that day is nearing. However it is certainly many years out.
jayd16 6y ago
You could split the difference and go C# or Java and use one of their web stacks.
qball 6y ago
>But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development. I think that day might be sooner than anyone thinks- Chromium is dominant enough now that their including Dart as a first-class language (or more likely, a successor to Dart) will likely be a viable strategy soon. Of course, the wildcard is Apple, but ultimately Dart can compile down to JS- being able to write in a far superior language that natively runs on 80% of the market and transpiles to the rest is suddenly much more of a winning proposition.

klelatti 6y ago

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?

chubot 6y ago

Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irrational-exuberance/ https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irra... We need to incorporate JavaScript and Python workloads into our evaluations. There are already standard benchmark suites for JavaScript performance in the browser, and we can include applications written in node.js (server-side JavaScript), Python web servers, and more. This is where cycles are being spent today, and we need evaluation that matches modern workloads. For example, we should care less if a proposed mobile chip or compiler optimization slows down SPEC, and care more if it speeds up Python or JavaScript!

FullyFunctional 6y ago
Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and has failed before (ie. Jazelle, picoJava, etc).
- sterlind 6y ago
  maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.
  - FullyFunctional 6y ago
    WASM is _designed_ to be easily jitted, without the expensive machinery we had to put in place to do this for x86, so the whole point is not require a new architecture. Because of this I find WASM to be the best direction yet for a "universal ISA" as it's very feasible to translate to most strange new radical architecture (like EDGE, Prodigy, etc). (Introducing a new ISA is almost impossible due to the cost of porting the world. RISC-V might be the last to succeed).

smt1 6y ago

Remember, don't think too hard about this stuff. It's better to meditate. You can apparently just telepathically learn this stuff by activating your paraterial lobe which can take 2-nary infos about learn to think about it as more generalized cognitive processes properly. Sharing = caring. I think it's best understood under a generalized ethnographic "utterance" aka linguistic and cultural problem in say a first order generalized theory of computing or combinatorics. aka the discrete log encoding::decode problem or the more ancient wisdom not passing down quick enough problem. When 2 group of static people of different cultures that some static group can just (lua) = implicitly define stuff very hard (combinatorical optimization) = branch and bound, it's better to remember than coding=calculate can be just thought as just a data structure problem (do a one time pad) in a generalized calculation in a automorphism and using techniques found in that abstract syntax tree that JavaScript can gradually typed more safely using TypeScript which Microsoft "already" gradually feed a generalized search engine (Google) knows so they can just Wikipedia (autocode the "Wisdom of the Crowds") it. I'd understand it by understanding first principles from logic and congitive sciences and applied software engineering. Software defined dynamic by necessity requires regularization to be very secure cryptographically to be ever exist in the first place. But remember you can think about it anything another way. This is basically doing a reinterpret_cast in classical first order C++. I personally think about it best as myself as a lexically scoped optimizing compiler using words compiled in some interior language to do a 1:1 mapping in Visual Studio to static analysis where my "utterances" can really apparently convince people that pattern matching stuff can really understood various matching techniques to recognize that these are just the same patterns. Basic elementary physics and elementary internet-networking things to do figure out some paradoxes: 1. why aren't people focusing on general energy scavenging in principle? Apparently other people are. But it requires change of focus in many respects. Basically you can on a computer on software do it safely, but in the physical world, you may accidentally be doing very non-sensical things like imagining that you can just do an inversion of gravity. 2. remember that bias exists, but history suggests that bias can be thought many different ways. your experiences bias you, but sometimes humans beings need to think automatically in new adductive reasoning inferential systems in safety. That can only be done to affect the real world in computer simulation. This can add to human knowledge though. Deductive and inductive and coinductive can be performed over arbitrary domains in whatever order theoretic ways. 3. remember these are just analogies. They can condition your mind, but could also let your brain think more clearly. 4. for example implicit::ego::bias (abc) problem. 5. everyone who knows signal processing knows singular "poles" as 0 can be patched up by more modern stable manifold theory but only people who understand that boundaries are just arbitrary of linear spaces. Remember than in the cultural sense of philosophy you can uw "hard" stuff once you understand traditionally thought of random [0,1] as boolean as more rich simplexes in the newer norm space [-1,1] which modern probability theory can be applied to. It creates a generalized system of norms of measurement of classical informational theory space. Sorry for being so cryptic but recall that you could understand that shannon for example "accidentally" created the information by creating information and commutation theory by autodualizing math and a implicit association of a simple easy to read 1 page document that created a "digital bit". Equated as entropy. You could understand say hibert who let his "school" understand inf dimensional spaces. I'll just point out a few free hugs in unicode spectrum (see https://home.unicode.org/emoji/emoji-frequency/ https://home.unicode.org/emoji/emoji-frequency/). I just understand to look at it using free glue guns but people will have to discover the right modulation schemes themselves in discrete logarithms but it may require say, for example, doing 3 simultaneous generalizations to combine 2 y-combinators of information theoretic boolean bits could be remodulated into L-R folded "cultural" to use experience to debias past implicit bias and use + forward thinking bias to auto create quasi-well ordered programs that computer science people have already created. let's just say I know by experience I know these things: 1. the www was originally created for people to collaborate over long distances to communicate more easily with clarity by being disconnected 2. social media was created for people to communicate as "new" ways but things facebook and twitter got too polluted by disinformation 3. telecomm systems eventually went from very messy error connecting codes modems and progressed to broadband by easing collaboration yet censorship still exists 4. search engine systems consuming more and more information to help locate stuff, but things like google get new bits of interformation to associations in their own internal db 5. it was at one time very hard to write international software but the invention of unicode helped people get access to the internet for the first time 6. the open/free source software like github and cultural practices like code reviews, allowed software developers for people around teams and corporations in remote areas to collaborate easily 7. computing devices like phones and smarter free computer languages allowed safer gradually and shifting codes of conduct to allow more open collaboration 8. the creation of cryptographic two session protocols allowed two parties security agree to securely exchange two exchange metadata together and work together 9. in applied software engineering, the creation of distributed version control systems like git and linux allowed mass adoption of free software 10. so these days in the software world you can just code software just by "coding" by pasting in semantic meaningful this is compositional software. 11. the productivity improvements in computer science has been enormous so that most people can save on energy both in hardware and software and refocus on more important stuff

offbynull 6y ago

Anyone else remember the ARM Jazelle DBX extension? I wonder if they'll end up dumping this in this the same way. I don't remember very many phones supporting DBX, but IIRC the ones that did seemed to run J2ME apps much smoother.

saagarjha 6y ago
This one is at least documented and in use by major browsers, so I doubt it will go away anytime soon.
masklinn 6y ago
It's quite different though, Jazelle literally implemented java bytecode in hardware. These instructions "merely" performs a float -> int conversion with JS semantics, such that implementations don't have to reimplement those semantics in software on ARM. The JS semantics probably match x86 so x86 gets an "unfair" edge and this is a way for ARM to improve their position.
repiret 6y ago
It takes a lot more silicon to implement Jazelle than a single well-tailored ALU instruction. Moreover, while the market for "JVM on small Arms" never really took off, the market for "JavaScript on Arms of all sizes" is flourishing and has been for at least a dozen years.

Animats 6y ago

Nice. Also useful is a set of integer operations that raise an exception on overflow.

barnacled 6y ago

It strikes me as ironic that an architecture that used to pride itself on being RISC and simple is heading in the same direction as intel-levels of masses of specialist instructions. I don't mean this as a criticism, I just wonder if this is really the optimum direction for a practical ISA

anaganisk 6y ago
May be as the time increases the threshold for being a RISC increases as the tech advances?
kmeisthax 6y ago
Ironically this instruction only exists because JavaScript accidentally inherited an Intel quirk in it's double-to-int conversion. This instruction should be "Floating Point Intel Convert" not "Floating Point Javascript Convert", but w/e, trademark laws and all that. In practice the instruction made code a few percent faster, primarily because it allowed dropping a few branches at the end of every JavaScript int conversion on ARM. IMO, ARM has always been at the "edge" of RISC (at least until AArch64 threw out all of it's quirks) and the exception proves the rule here. Instructions like this exist specifically because they accelerate execution time, rather than for assembler programmer convenience. That's the same underlying reason why RISC had such an advantage over CISC before micro-op decoders and register renaming became a thing. It's not so much that "having less instructions is better", but that things like memory operands or repeat prefixes or what have you primarily act as programmer convenience at the expense of code efficiency. Stuff like FJCVTZS is used by compiled code to gain a measurable speed benefit, ergo it stays in.

dboreham 6y ago

All cpu have instructions with nsa in the name. Well not in the name, but added at their behest at some point in history.

bitwize 6y ago

The dream of the Lisp machine is long dead. Our computers are now JavaScript machines.

lxe 6y ago

A good follow up to "HTML5 Hardware Accelerator Card" from yesterday: https://news.ycombinator.com/item?id=24806089 https://news.ycombinator.com/item?id=24806089