2 ms·

> Much like x86, ARM is just old nowadays I disagree: ARM64 is from 2011, it's not that old and it was a significant ISA makeover.

• snvzz 4y ago
  They lost thumb2's advantage in code density. Thumb was what made ARM a good ISA. I have no idea what ARM's thinking at this point.
  • brucehoult 4y ago
    Yup. ARMv4T (two modes with 32 bit and 16 bit instructions) was what got ARM's foot in the door with Nokia, but it was Thumb2 (ARMv7) that sealed the deal and led directly to ARM's current dominance in mobile and embedded. Abandoning all that for a fixed-length 32 bit opcode 64 bit instruction set with just barely better code density than original ARM (and dropping the stuff that made sense in 1985 but doesn't today, such as predication everywhere and load/store multiple) just looked like lunacy to me in 2012 when I read the Aarch64 manual, and looked even worse when RISC-V came out with a 64 bit instruction set using the same basic idea as Thumb2. If you're doing very wide instruction decode then two instruction lengths is a little harder to handle then one, but not enough to matter, at least at 8- or 16-wide. You can EITHER 1) put a 2:1 32 bit mux in front of half of the decoders if you don't want much extra hardware, OR 2) build 50% more decoders and put bigger 2:1 muxes on the outputs of the decoders. The latter is slightly faster because you have to examine 2 bits out of each 16 bit parcel in the instruction stream to decide which mux input to choose, and option 2) lets you do that in parallel with the decoding instead of having to do it before the decoders. It's just completely incomparable to doing wide decode on x86_64 where you have to deal with 1-15 byte instructions with an arbitrary number of prefix bytes and several opcode bytes to decode before you know the length of an instruction, and therefore where the next instruction starts. If the first instruction starts at offset 0 then the second instruction can start anywhere from offset 1 to 16, the third instruction can start anywhere from offset 2 to 31, the fourth instruction anywhere from offset 3 to 46 etc.
  • renox 4y ago
    > I have no idea what ARM's thinking at this point. Focussing on desktop and servers.. It worked. In a similar fashion RISC-V has things which makes little sense for "high performance" (16-bit aligned 32bit instructions with the C extension, too simple addressing mode) which shows that their main goal is embedded..
    • snvzz 4y ago
      >has things which makes little sense for "high performance" Such as? >(16-bit aligned 32bit instructions with the C extension) For virtually no cost (see brucehoult reply to my parent post), it brings greatly increased code density, which means more code fits in L1, or same thing, that you can make it smaller and clock it higher. This actually benefits high performance microarchitectures greatly. See M1's L1 size for an example of why ARMv9 AArch64 is mind-blowingly bad. ARM's literally lost its marbles. >(too simple addressing mode) More complex addressing modes were evaluated and discarded, as they only brought harm, no benefit. This is a pattern in RISC-V, where decisions were made after careful weighting, rather than some individual's favored way of doing things.