5 ms·

> So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all. This isn’t true. They had a MODAL decod

• brucehoult 5y ago
  Uhhh .. while overall I agree more with you and less with klelatti, you appear to have missed Thumb2, introduced in 2003. Original Thumb was 16 bit opcodes only, and you could switch modes in a program between Thumb mode and ARM mode but not mix 16 and 32 bit instructions together. With Thumb2, 32 bit opcodes (completely different to original ARM opcodes) were added to the original Thumb 16 bit opcodes, and you can freely intermix them, just as you can with RISC-V with the C extension. With ARMv7 Thumb2 is the standard execution mode used on iPhones and Android and so forth. While ARM's Cortex-A application processors continue to implement original ARM mode, the Cortex-M series is Thumb2 only (except the M0(+), which is Thumb1 plus just a couple of 32 bit instructions). I'm personally surprised that ARM dropped 16 bit opcodes in their 64 bit ISA -- I was right from when I first read the manual in 2012. It hurts code density a lot. They pretty much managed to match x86_64 and maybe they thought that was the only competition they would have and it was good enough. It's true that fixed length instructions simplifies very wide decoders. But ARM has not after ten years built a core with a very wide decoder. Only Apple has. And having two lengths doesn't hurt much, especially when you can tell which length you have from examining just a couple of bits in the instruction (two bits in RISC-V, three bits in Thumb2). It's certainly much much easier than x86 where you have to decode a potentially unlimited number of prefix bytes, several opcode bytes, AND a possible modrm byte just to figure out how long the instruction is. Even x86 is a solved problem. For cold code you have to do it the hard way, but for frequently executed code in loops or common subroutines you can just add a few extra bits to each byte (or block) in the instruction cache storing the length of each instruction calculated the last time it was executed. As instructions are limited to 15 bytes, in the simplest (but most wasteful) implementation you need to add 4 bits to each byte indicating the length of the instruction that starts there. But adding a single bit to each byte indicating whether an instruction starts there would do the job too. Solved problem, basically. That extra bit makes the instruction cache 12.5% bigger, but this is more than made up for by the 25% to 30% code size reduction from having 16 bit instructions available. And with only two instruction lengths it's probably not even necessary.
  • klelatti 5y ago
    The development of A64 took four years. Arm was completely familiar with 16 bit opcodes having used them in thumb for years. There would have been extensive testing of the impact of various ISA decisions - including use of 16 bit opcodes - in the course of that development. But it’s obviously possible to prove that they made a major mistake and left significant performance on the table in a couple of paragraphs in a HN comment! Sorry, yet again there is no current real world evidence that RISC-V can outperform Arm64 by the 20% quoted in the parent comment. And with that I'm done!
    • brucehoult 5y ago
      And here we again have the assertion that ARM engineers think very hard and therefore never make mistakes. Do you think Intel engineers don't think very hard? Oops, Pentium 4. Oops Itanium. And that was after Pentium Pro wiped the floor with DEC, Sun, MIPS and the rest. ARM engineers are mortal too.
      • klelatti 5y ago
        That's not what I said! Rather its vanishingly unlikely they would discard an ISA feature that was one of the reasons for Arm's success (Thumb was key in ARM7TDMI getting into Nokia etc) casually and without a great deal of analysis of real world code. And there is no evidence whatsoever of an advantage of the order of 20% that the original comment stated. Pointing to Intel's errors (the disasters of iAPX432 and Itanium are probably more pertinent) really just highlights how consistently Arm have got ISA design right over the years.
        • brucehoult 5y ago
          ARM have got a long list of discarded or ignored technologies too. They've had several attempts at SIMD, and even when they did SVE it turned out that the "Scalable" didn't extend down to microcontrollers like RISC-V's V extension does and they've had to introduce the slightly different and incompatible MVE as well to cover that. It will be interesting to see what happens in a few years when some applications start to want vector registers longer than 4096 bits, the upper limit by design of SVE's scalability. And then there are things such as Jazelle and T2EE. I firmly believe -- and have since it was announced in 2012 -- that the fixed length nature of aarch64 will eventually prove to be a mistake. Code density is important. They could do a mode like Thumb in the ARM7TDMI (which I have a ton of experience with), but it was Thumb2 in the Cortex series which really propelled ARM to their current heights. There is no room in the aarch64 encoding to do a Thumb2. It would need an entirely new ISA encoding. I think what probably happened is ARM managed to roughly match the (pretty awful) code density of x86_64 with a fixed length encoding and decided that was good enough as x86_64 was the only competition they were going to face in the 64 bit space. Except it's not.
• klelatti 5y ago
  > ARM either had a solid delivery of their new ISA in 2011, or MIPS 64 was going to kill them. > Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company. > It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor. Sorry you're just making stuff up now. I'm happy to engage on a real comparison of the pros and cons of each architecture but this just isn't correct.