3 ms·

> ARM has the various Thumb encodings, Jazelle, VFP, NEON and more. Having done just a tiny bit of compiler development for ARM, I can assure you that having a

> ARM has the various Thumb encodings, Jazelle, VFP, NEON and more. Having done just a tiny bit of compiler development for ARM, I can assure you that having all of these variants is a pain. Making compiler writers' lives harder means you're less likely to get optimal performance. At least on the more exotic variants, but possibly even on the most common ones.

blueflow 6y ago
> I believe the author doesn't identify as a "guy". I don't think this was meant as assumption about the authors gender. The same way i wouldn't assume that there is physical, actual pain involved when you said "having all of these variants is a pain" even when you literally wrote it.
floatboth 6y ago
All this Thumb etc. stuff is not relevant to the 64-bit world though. AArch64 is the least fragmented of the big ISAs, with a solid list of base functionality — e.g. NEON is guaranteed to exist on everything.
- plorkyeran 6y ago
  That's mostly because it's new and hasn't had time to fragment. NEON everywhere is great, but eventually there's going to be a NEON 2 that obviously will only exist on newer chips. People seem to generally regard thumb encodings as a mistake so we probably won't get a repeat of that, but I'd be shocked if similar divergences don't develop over the years.
  - cesarb 6y ago
    > but eventually there's going to be a NEON 2 that obviously will only exist on newer chips. Isn't it SVE? So far, it has been only implemented AFAIK by the A64FX, which is used by the current #1 supercomputer in the TOP500 list, but it wouldn't surprise me if we start seeing it on newer 64-bit ARM chips.
    - my123 6y ago
      Neoverse V1 has SVE (with 2x256b units) and Neoverse N2 has SVE2 (w/ 2x128b units). Note that SVE is a superset of Neon and SVE2 is a superset of SVE.
    - skavi 6y ago
      SVE2 is guaranteed in ARMv9.
  - brandmeyer 6y ago
    ARMv8 is 8 years old at this point. RISC-V's 2.2 (final, stable) ISA came out in 2017 and its already fragmented.
  - Symmetry 6y ago
    Thumb is very useful in things like microwaves where using less memory save the manufacturer a little money. You do have different chips with different instructions but in a very regularized way. An ARM v8.2-A chip is going to have the same instructions whether it's made by ARM, Samsung, or Apple. And when v9 comes out they'll have NEON's SVE replacement everywhere and you'll be able to use the same code regardless of whether the SIMD width is 128 bits or 512.
    - ksec 6y ago
      Is that SVE on ARM v9 confirmed? I have yet to see any concrete details on ARM v9, generally speaking ARM v8 is pretty damn well designed I am wondering what v9 will look like.
      - skavi 6y ago
        It’s generally expected that SVE2 will be required for ARMv9. SVE2 is a more logical successor to NEON than SVE. https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture https://community.arm.com/developer/ip-products/processors/b...
- brucehoult 6y ago
  NEON is guaranteed to exist on everything, and this means you're never going to see Aarch64 replace the Cortex M0 and M3. That's fragmentation right there. Severe fragmentation. Two completely incompatible ISAs. Small 32 bit RISC-V comes in smaller and lower power than An M0, and small 64 bit RISC-V is not much bigger than an M0 and is rather popular controlling something in the corner of a larger 64 bit SoC.
simias 6y ago
>Having done just a tiny bit of compiler development for ARM, I can assure you that having all of these variants is a pain. Making compiler writers' lives harder means you're less likely to get optimal performance. At least on the more exotic variants, but possibly even on the most common ones. I can empathize, but isn't that just part of the job of making a compiler? Any successful, long-lived ISA is going to have extensions and revisions that will need to be handled in the toolchain. I guess my point is not so much that it isn't painful, it's more that I don't really see what makes RISC-V really different besides the fact that it's a younger ISA and therefore we don't already know for sure which extensions are going to become de-facto standard and which ones will be less common. >I believe the author doesn't identify as a "guy". Arg, of course the one time I don't use gender-neutral language I manage to mess it up. Edited, thanks.
pizlonator 6y ago
As a compiler pro, I view availability of better instructions to select as an asset rather than as a liability. Sure it’s more work for me and my team but if it makes shit fast then who cares how much work it was. One of the best lessons I got when I was being inducted into the compiler club was: compilers are hard. It’s a hard job so other people can have easier jobs. It’s ok if compilers turn complex and managing that complexity is just something you have to learn to do. I don’t think it’s true that the need for that complexity leads to lower perf.
notanotherycom1 6y ago
I don't understand why is it a pain? Are you saying it makes choosing what encoding/extension more difficult? I would only see this as a pain if you had to mix/match these extensions and one isn't guaranteed to exist when another does making you have to write several versions for every mix and match. But I kind of assumed most ops perform well enough and important optimizations have a test case for and will get done

blueflow 6y ago

> I believe the author doesn't identify as a "guy". I don't think this was meant as assumption about the authors gender. The same way i wouldn't assume that there is physical, actual pain involved when you said "having all of these variants is a pain" even when you literally wrote it.

floatboth 6y ago

All this Thumb etc. stuff is not relevant to the 64-bit world though. AArch64 is the least fragmented of the big ISAs, with a solid list of base functionality — e.g. NEON is guaranteed to exist on everything.

plorkyeran 6y ago
That's mostly because it's new and hasn't had time to fragment. NEON everywhere is great, but eventually there's going to be a NEON 2 that obviously will only exist on newer chips. People seem to generally regard thumb encodings as a mistake so we probably won't get a repeat of that, but I'd be shocked if similar divergences don't develop over the years.
- cesarb 6y ago
  > but eventually there's going to be a NEON 2 that obviously will only exist on newer chips. Isn't it SVE? So far, it has been only implemented AFAIK by the A64FX, which is used by the current #1 supercomputer in the TOP500 list, but it wouldn't surprise me if we start seeing it on newer 64-bit ARM chips.
  - my123 6y ago
    Neoverse V1 has SVE (with 2x256b units) and Neoverse N2 has SVE2 (w/ 2x128b units). Note that SVE is a superset of Neon and SVE2 is a superset of SVE.
  - skavi 6y ago
    SVE2 is guaranteed in ARMv9.
- brandmeyer 6y ago
  ARMv8 is 8 years old at this point. RISC-V's 2.2 (final, stable) ISA came out in 2017 and its already fragmented.
- Symmetry 6y ago
  Thumb is very useful in things like microwaves where using less memory save the manufacturer a little money. You do have different chips with different instructions but in a very regularized way. An ARM v8.2-A chip is going to have the same instructions whether it's made by ARM, Samsung, or Apple. And when v9 comes out they'll have NEON's SVE replacement everywhere and you'll be able to use the same code regardless of whether the SIMD width is 128 bits or 512.
  - ksec 6y ago
    Is that SVE on ARM v9 confirmed? I have yet to see any concrete details on ARM v9, generally speaking ARM v8 is pretty damn well designed I am wondering what v9 will look like.
    - skavi 6y ago
      It’s generally expected that SVE2 will be required for ARMv9. SVE2 is a more logical successor to NEON than SVE. https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture https://community.arm.com/developer/ip-products/processors/b...
brucehoult 6y ago
NEON is guaranteed to exist on everything, and this means you're never going to see Aarch64 replace the Cortex M0 and M3. That's fragmentation right there. Severe fragmentation. Two completely incompatible ISAs. Small 32 bit RISC-V comes in smaller and lower power than An M0, and small 64 bit RISC-V is not much bigger than an M0 and is rather popular controlling something in the corner of a larger 64 bit SoC.

simias 6y ago

>Having done just a tiny bit of compiler development for ARM, I can assure you that having all of these variants is a pain. Making compiler writers' lives harder means you're less likely to get optimal performance. At least on the more exotic variants, but possibly even on the most common ones. I can empathize, but isn't that just part of the job of making a compiler? Any successful, long-lived ISA is going to have extensions and revisions that will need to be handled in the toolchain. I guess my point is not so much that it isn't painful, it's more that I don't really see what makes RISC-V really different besides the fact that it's a younger ISA and therefore we don't already know for sure which extensions are going to become de-facto standard and which ones will be less common. >I believe the author doesn't identify as a "guy". Arg, of course the one time I don't use gender-neutral language I manage to mess it up. Edited, thanks.

pizlonator 6y ago

As a compiler pro, I view availability of better instructions to select as an asset rather than as a liability. Sure it’s more work for me and my team but if it makes shit fast then who cares how much work it was. One of the best lessons I got when I was being inducted into the compiler club was: compilers are hard. It’s a hard job so other people can have easier jobs. It’s ok if compilers turn complex and managing that complexity is just something you have to learn to do. I don’t think it’s true that the need for that complexity leads to lower perf.

notanotherycom1 6y ago

I don't understand why is it a pain? Are you saying it makes choosing what encoding/extension more difficult? I would only see this as a pain if you had to mix/match these extensions and one isn't guaranteed to exist when another does making you have to write several versions for every mix and match. But I kind of assumed most ops perform well enough and important optimizations have a test case for and will get done