7 ms·
I enjoyed reading this a lot, I keep seeing RISC-V being touted as a potential replacement for ARM but I had yet to read a good critique of the ISA by people wh
by simias 6y ago
I enjoyed reading this a lot, I keep seeing RISC-V being touted as a potential replacement for ARM but I had yet to read a good critique of the ISA by people who know what they're talking about.
This point I didn't quite understand:
>Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care.
Most successful ISAs (including ARM) have their share of extensions, coprocessors, optional opcodes etc... ARM has the various Thumb encodings, Jazelle, VFP, NEON and more. Toolchains and embedded developers are used to dealing with optional features of computers, I'm not sure why RISC-V would fare worse here.
Beyond that I notice that many of the ascribed weaknesses are shared with other RISC ISAs like MIPS (but not ARM):
- No condition codes
- Less powerful, simpler instructions that require more opcodes to do the same thing but can potentially run faster.
- No MOV instruction
- The "unconstrained extensibility" is arguably a thing on MIPS too, with the four coprocessors that can be used to implement all sorts of custom logic.
Of course ARM has been more successful than MIPS, so maybe it's a sign that those things are indeed bad idea but given that this comes from an ARM dev I wonder if part of it is not just "that's now how ARM does it".
On the other hand I must say that I was surprised that RISC-V made multiplication optional, in this day and age it seems like such a useful instructions that it's well worth the die area. Optional DIV I can understand, but an ISA without MUL? That's rough, even for small microcontroller-type scenarios.
- tom_mellior 6y ago> 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 agoAll 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 agoThat'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.
- brandmeyer 6y agoARMv8 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 agoThumb 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.
- 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 agoAs 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 agoI 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
- klelatti 6y agoThe point on unconstrained extensibility I think is largely around the fact that anyone can add extensions wheras with ARM, the company retains control. There are advantages to the RISC-V approach it is likely to lead to more fragmentation - and worse gives the ability for a major implementation to add proprietary extensions that are not licensed to anyone else putting smaller players at a disadvantage and leading to fragmentation, not only in the hardware but also in the software ecosystems. Whilst you may not like ARM having control at least everyone (for a fee) has full access to the ISA and implementations.
- Symmetry 6y agoThe extensibility that leads to the danger of fragmentation for general purpose computing is a great advantage for embedded computing where your software or firmware is targeting one particular piece of hardware and doesn't have to be compatible with anyone else. Western Digital is free to put in the mix instructions they need for their hard driver controllers and NVidia is free to put in the instructions they need to control their video cards and the incompatibility between them just doesn't matter.
- klelatti 6y agoWhich is great and fine as no-one else will be writing software for that particular hardware. I believe that ARM has been allowing some extensions for their M series designs in these circumstances - partly due to pressure from RISC-V alternatives. I should add that I think that it's possible that Nvidia/ARM combination will remove ARMs 'level playing field' and we might see Nvidia only extensions for their designs - which would not be good. We'll have to see.
- leeter 6y agoExample: The Commodore 128 (or the Plus/4 works too). The C128 had a more powerful CPU capable of 16-bit work, accessing more RAM, faster Disk access etc. But in general it was rarely targeted. Why? Because developers were looking for the widest degree of compatibility and that meant restricting themselves to the minimal possible subset of compatibility between the C128 and the C64. This meant that by and large the 128KB of ram went unused as most applications ran in C64 mode. The same applies here: the more extensions and things you pile on... the less likely they are to get used unless they are de-facto mandatory. Even today you can see games getting released that won't touch AVX instructions on both Intel and AMD because of compatibility reasons. Valve provides data to developers on penetration of various ISA extensions via the hardware survey ( https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam#cat13 https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... ) but for RISC-V there is no way to do the same. So most utility writers will be highly constrained in what they will use in terms of expected extension use, that will have significant harms in terms of performance. Alternatively it requires recompiling for every single different target, which is also likely. In essence: you need a good baseline of compatibility for people to expect to use. It makes moving software easier between targets. A piece of software might certify for example on R64GC but not on R32IF because the double precision emulation might not work as expected or the lack of carry could be an issue etc.
- simonh 6y agoFor embedded applications, which are RISC-V’s bread and butter, the hardware and software are designed hand in glove. Eg if you are designing a custom RISC-V chip for a media encoding system you will want extensions for that application, and make use of those in your development tool chain. The software for your Hardware, or at least the performance and functionality critical part, is often only targeted at your hardware, not any arbitrary RISC-V system.
- devit 6y agoThis is just a tooling problem that can be solved trivially by having release builds build multiple binaries by default, for all the major extension profiles.
- notanotherycom1 6y ago> I had yet to read a good critique of the ISA by people who know what they're talking about. I still wonder about RISC-V. To me, it seems pointless. But a lot of companies are buying into it so I'm wrong Why would you ever want a standard ISA? If you're buying chips you either want a cheap standard one or a powerful efficient one. To be efficient (or cheap) you'd want to only support what's required and what works best with the implementation. I don't really understand the point of a generic ISA. Why not have some kind of bytecode or standard format (like llvm-ir) that gets optimized for the CPU and gets a native binary that doesn't need interpretation. Like how the f* is it easier to make something regular+generic fast rather than something custom for your hardware/chip/cpu fast? Do you want to know how many times I used XML when it's not required? 0. Do you know how many times I used SQLite or my own binary file? I lost count. SQLite has far more constraints than XML and custom binary files/formats aren't hard after you done than a few times.
- eddyb 6y agoBetting on smart compilers without putting in the effort to build them is how the Itanic happened.
- notanotherycom1 6y agoDamn dude. I never thought of that. So are you here right now declaring that RISC-V and all those companies are in the wrong and risc-v will be a disaster? Cause I might agree and be with you on that lol -Edit- I have no idea what the state of the compiler is https://github.com/riscv/riscv-gnu-toolchain https://github.com/riscv/riscv-gnu-toolchain > Warning: git clone takes around 6.65 GB of disk and download size WTF? If you're going that complex than... wtf?
- eddyb 6y agoNot at all, RISC-V doesn't need extremely clever compilers, and instead it's designed to maximize what the microarchitectures (hardware implementations) can do, and reduce unnecessary overhead. My reply was mostly aimed at the idea that you can move the complexity from hardware into compilers: it might be possible, but we know how to build out-of-order CPU better than we know how to build smart compilers, so you have to invest a lot more research time, and it's generally a lower priority. Even innovations from the past decade or two, like VSDG, haven't made their way into "industrial" compilers yet. As for the size thing: GCC and Clang are huge (at least when you include their entire change history, which git does), RISC-V is comparatively only a tiny part of them, you should probably look into that further before jumping to conclusions. You don't even need a whole separate toolchain with Clang or Rust, the whole "need to build GCC yourself to cross-compile" is outdated GNU tradition, not some kind of technical necessity.