-
-
-
Hear hear. <3 Author, thank you for writing this!
I think a lot of the point is that, at some level, it doesn't really matter how good or bad an ISA is for a given task anymore. It does matter, but the delta between a good ISA and terribly mediocre one is really not so big that some hardware and software work can't overcome it. Sucks for the hardware or software makers sure, but the benefits of their work scale nearly indefinitely. The Ky X1 CPU on the Orange Pi RV2 might be 10% better or cheaper if it used an ISA better for big out-of-order chips, but... you can't buy those chips because they don't exist, so the 10% really doesn't matter to the end user. What does that 10% overhead buy you? The ability to use basically the same compilers, debuggers, docs, debugging hardware, etc for a huge variety of chips. That 10% overhead is apparently far, far less than the cost of ARM licensing.
-
I think this severely misunderstands the article it's responding to.
The fact that you can assemble a jumble of RISC-V extensions into something that fits any particular space, does not mean that it fits the space well. You can do meaningfully better than RV32EC if you focus on the parts that are important for the market segment that wants that. You can also do meaningfully better than RVA23 if you focus on the parts that are important for the market segment that wants that. It's not that RISC-V can't flex across segments, it's that it's sacrificing stuff to be able to flex.
The boundaries are very much architectural wrt. core design. MMU's have little to do with the design of the core, and you can realistically add them anywhere, yes. But that's very much not the border between application cores and embedded cores, it's the performance and silicon area goals. And you want to design very differently depending on these goals, ISA included.
The whole thesis of the article that this is responding to is that technical design has no relation as to why the architecture got popular. Basically any architecture that was similarly open and was similarly promoted during the time would have gotten as popular. The point is that the one that got popular is pretty bad from the technical design, not that it's bad that it got popular or something similar.
-
We always need more of this: positivity, perspective, and possibilities. This is how open source and royalty free wins. Let's build each other up and make something special with what we have, empowering people in all parts of the world. I'm excited to check out their videos and learn more about what they've been working on!
It just feels good, y'know?
-
This is a fantastic, articulate response that exhibits the kind of rhetorical good faith I criticized the original article for lacking.
-
Actual blog post submitted yesterday: https://lobste.rs/s/pu3yzg/risc_v_they_should_have_known_better
-
I was (initially) so confused by this article as I missed the first one, and then misread the title as "A Third World Embedded Engineer Responds to RISC-V: They Should Have Known Better" - e.g. essentially picking up the title of the article it was rebutting.
I am a highly skilled reader :D
(There's a bit on x86 at that end :D)
That said it remains weird to me that people continue to put far so much emphasis on the ISA as the thing that determines "is this performance or is this lower power". The ISA itself has negligible impact on that. The implementation of the ISA is what drives it.
This is why Big.Little (or I thing on some Qualcomm cores: Big.Medium.Little?) is possible: it's the exact same ISA from the highest power to the lowest, and the size of the high performance variance is gigantic compared to the low power cores because the performance/power tradeoff is overwhelmingly the result of the implementation of the ISA.
Anything high power is going to have longer and wider pipelines, long OoO buffers, larger ücode catches, more complex ücode implementations, can fuse a wider array of üops, etc, etc. A low power variants does not need any of these at all.
At the very lowest end of the power spectrum code density starts to become a significant portion of total power usage than decoding. This is one of the reasons RISCV and ARM introduced 16bit instructions (note: RISCV does not have the arm 32bit alignment guarantees as the base unit of the ISA encoding is 16 bits) - the other reason of course being in low power environments you want minimal ram due to cost, capacity(In ultra low power environments SRAM is better, but limits available ram), and power usage (see footnote).
Anyway, once you're at this point the user facing ISA simply does not matter.
Footnote on x86:
You can of course design an ISA with the intent of making it expensive, and x86 is an example of an ISA that is expensive (though obviously not by intent) - the instruction decoding is unavoidably expensive (RISCV's variable length encoding includes the instruction length explicitly in the first packet of the instruction), and then has to converts the small number of registers into a ücode program operating on a larger set of registers.
But assuming you aren't in that position the relative cost is negligible.
Foot note on DRAM refresh power usage: In a laptop for example, while idle, with the screen on, dram refresh can exceed 10% of total power usage, in the deep sleep modes it generally exceeds 50% of the total power draw. I don't know the current LPDDR power usage, but back in the DDR4 generation going from 16-32gb of ram resulted in around a 30 to 45minute reduction in deep sleep battery life.
-
The ISA can have a big effect on performance in the medium-to-medium-high complexity range, before you get into "intel/amd/apple" implementation quality but after you have OoO and a complex cache hierarchy and instruction cracking/fusing and microcode etc. Mostly in terms of how painful it is on memory/cache pressure and how many weird pipeline stalls there are (that a sufficiently complex or sufficiently simple design would avoid). RV avoids a lot of weird pipeline stalls but then it turns around and makes a lot of cache-hostile decisions; lots of really common patterns that are super short in x86/64 and arm are really long in RV. When you dig into the specifics of these patterns, IMO it ends up not looking well-earned why they look the way they do instead of having shorter first-class features. It might be a strawman, but it looks like designing for "freshman academic toy (as in, literal bottom tier entry level)" MCUs that don't have the frontend features that even the weakest real-world deployed MCUs have (modern ones, not ones from 20+ years ago, and not weird task-specific chips like the ones for solar panel calculators) allowed weird imagined constraints to negatively affect the design of common features.
But it's not a BIG problem. It's basically marginal. It just looks bad. But IMO it really does look bad, and qualcomm's idea for how compressed instructions could have been done instead is an example of how much better the situation could have been. We could've had "almost-perfect ISA for every category", instead we have "different categories fighting for support and leading to weird compromises". Not having the next 2 shift-add sizes is an example of this. 16-byte arrays are super ultra incredibly common today, but RV has the same performance cliff between 8-byte and 16-byte array access that x86 has, for seemingly no good reason.
-
-
-
-
I pay anywhere from US $60 to US $200 to ship one dollar chips that people everywhere else get free shipping on.
Oof. Trinidad and Tobago must have a terribly expensive postal service or customs rules.
-
It's a bit complicated, but fundamentally most of that cost goes to the mail service used to ship it originally, and a smaller part goes to the Trinidad and Tobago mail service as part of the UPU remuneration system. This means that the cost heavily depends on the origin.
Ultimately, most places that sell things don't bother implementing shipping with multiple couriers, which means cost can vary wildly unless you're smack dab in the middle of some major city. Hell, for example, I have the audacity of living in Northern Sweden, which means any DHL shipment costs €15 extra.
-
-
Better the ISA with some glaring oversights that's free and much more usable by everyone than a flawless ISA that either costs more than some can afford or that doesn't exist.
I like my RISC-V hardware, even if the performance is mediocre. Competition is good, and we definitely don't need an amd64 / Arm duopoly.
-
I'd rather have more people using Power ISA, which is also open, and IBM even publishes some cores for people to use (Microwatt, A2I/A2O, etc.). Plus you can get desktop-performance hardware today. POWER9 is a little long in the tooth now, but it's still credible.
But I guess worse, or at least cheaper, is better.
-
I've always said the Power world would be different if we had a Raspberry Pi size / price Power SBC. The closest thing, AFAIK, is the Nintendo Wii U.
-
-
Which is of course arm now, with the ppc parts carrying a premium (compare e.g. T1023/LS1023A) and stuck on DPAA.
-
-
-
-
China is also investing heavily in RISC-V after sanctions on Huawei demonstrated both x86-64 and ARM are intolerable SPOFs for their sovereignty. It’s only a matter of time until they catch up, and whatever flaws the RISC-V architecture has are trivial compared to the dog’s breakfast that is x86, that somehow still managed to scale.
-
-
The article misses one other annoying limitation: the limited call/jump distance of +/-1MiB, solely for pureness of the ISA -- this is clearly insufficient for any larger application. Even 32-bit ARM wasn't that limited despite their condition-code encoding (+/-32MiB), MIPS and AArch64 have +/-128MiB, x86 has +/-2GiB.
Compilers have to emit the long jump sequence (lui+jalr) and rely on linker relaxation to merge these if the offset is small enough. This relaxation makes all offsets inside text sections non-constants, requiring a plethora of further relocations in everything that references into text sections (e.g. debug info, unwind info). (MaskRay also wrote about that here.)
The jump and link instruction in RISC-V is the weird, it’s a full major opcode, so consumes an enormous amount of encoding space. It uses five bits to specify the link register which, in almost all cases, is either zero (don’t link) or ra (use the ABI-defined link register). To my knowledge, no other RISC ISA does this, they all use one bit to differentiate these cases. RISC-V occasionally uses an alternative link register to do outlining, but that’s something you could encode with two bits (even specifying two alternative link registers), which would make the same instruction use 1/8th the encoding space.
They did this because they had a notion of purity in the design that meant they didn’t want to leak ABI details into the ISA, which is exactly the opposite of how you do good hardware-software co-design (what is the ISA for, if not running software that targets the ABI?). But they failed at even this, because branch predictors really want to do return-address prediction and so branches with ra as the link register are treated as calls and branches with ra as the target and zero as the link register are treated as returns and the ISA even contains a note recommending this.
On top of that, it has both a large immediate displacement and a register for the target. The reason for having both is so that you can do large position-independent jumps with the sequence of auipc (add unsigned immediate to PC, which takes a single target register and an enormous immediate that is left shifted by enough that the combination of it and the jump’s immediate are sufficient for a 4 GiB range).
But auipc is annoying because, unlike addrp in AArch64, it’s hard to reuse the result because it’s adding the high bits, rather than setting them (gcc had a bug where they tried to do the same transform with RISC-V that works on AArch64 and it worked most of the time).
Having the jump instruction use eight times as much encoding space as it should means that the 32-bit encoding space is very scarce.
I am working on being more polite with my words, but this article is a real struggle given the author's attitude. RISC-V was designed by academics and industry veterans with decades of experience. They certainly knew better than the OP.
Complaining about modularity is the thing that makes it so RISC-V doesn't carve mistakes in stone forever, like the proprietary ISAs do. While standard profiles must go through a committee of actual implementers, the modularity OP is complaining about makes it so anyone who has a need for a different set of instructions (including proprietary ones) can do so. Qualcomm did this while developing some silicon and proposed changes. The committee thinks it's a good idea, so those changes will probably go into a future version.
The OP is free to make their own profile and very much encouraged to try and make it a standard! Instead they argue that the only reason the inventors of RISC didn't adopt their preferred open ISA is NIMBYism. This rant is like an undergrad getting frustrated with their homework and calling the professor and authors of the textbook stupid.
While I'm saddened to see it getting voted up so much on Lobsters and elsewhere, the community is pretty burnt out re-explaining this stuff to the non-curious. I'll update this comment if we get around to creating a FAQ for this type of content on the r/riscv wiki.
I don't think you have to be polite given the article's tone. You might however want to be more persuasive than appealing to authority (the inventors of RISC and all - they previously invented MIPS, which went under, unlike x86 which AFAIK they predicted would go under; Itanium was also held in high regard by academics, etc.) Also the author is clearly fairly experienced at low levels of abstraction, if not necessarily in CPU design. If you got tired of explaining this stuff, surely there are links to writeups with such explanations you could share for those of us who actually are curious. And you don't owe this to anyone, of course, I just think it would work better than attacking the author (who had it coming given his tone, but still)
I am at one of the not so numerous places using high end RISC V cores BTW and the ecosystem fragmentation due to the most basic things not being standardized is a real problem
I appreciate your constructive feedback! I would have been better off not posting anything instead of dumping incomplete thoughts and rage quitting late at night.
I agree that the appeal to authority isn't a technical argument. It was 100% the result of burnout of dealing with similar situations in which people justify becoming dysregulated over engineering choices. I want to help, but their dysregulation becomes a barrier to productive discussion. But pointing out similar situations isn't going to convince the OP of anything about their behavior.
I still don't have time to give a good technical point-by-point overview here, but I will note that ISAs barely matter to performance. It's a rounding error compared to everything else that goes into a chip's design and manufacturing. Even if one accepts his technical choices as superior, the claims about major performance ramifications are hyperbolic.
Again, that was an incomplete thought and I agree 100% that fragmentation is a headache. I disagree with framing modularity as a mistake that encourages fragmentation.
Operating systems based on Linux are extremely fragmented because anyone can spin up their own distro. But the lack of fragmentation in the OS X and Windows ecosystems is the result of their owners shipping a small number of flavors for each and not allowing anyone else to build their own. Linux is a perfectly suitable kernel to base an OS on that maintains binary compatibility: Red Hat has been doing that for a long time! Apple could 100% switch to Linux and RISC-V with zero fragmentation within their ecosystem because they control the entire hardware/software stack.
Proprietary ISA's also have fragmentation between generations, vendors, product lines, and sometimes even between cores in the same chip. AMD will release a new instruction, Intel will eventually adopt their own slightly incompatible version, which AMD then has to add support for in addition to their original extension. Extensions for HW acceleration (like crypto) are notorious for being "supported" in chips that just emulate them in software (sometimes incorrectly).
Fragmentation is inevitable for any ISA and a popular open ISA is going to have more fragmentation because manufacturers will fork whenever it saves them money. RISC-V has features that make it easier to ship a custom ISA, which is spun as encouraging fragmentation. But it certainly isn't the case that RISC-V's designers didn't know that fragmentation would be a problem and that modularity is a mistake: RISC-V's modularity is the result of anticipating these inevitable sources of fragmentation and trying to make it less painful.
Aaaaand there I go, spending all that time I don't have on internet comments!
You're missing the point, and I suggest that you look at the author's area of interest.
He has a creditable track record writing emulators (for ARM and MIPS) to run on improbably-small host chips, and while he makes no claim that they are other than curios (Linux doesn't exactly run fast on them) it definitely confers a significant amount of "street cred".
https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit
https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard
Can you claim comparable experience?
It saddens me that legitimate criticism is dismissed out of hand without addressing any of the points within. "Surely the inventors of RISC-V, smart and capable people, had some reason for making the choices they did. If OP doesn't like it, perhaps they should make their own ISA, with blackjack and hookers. The upvotes must all be coming from toxic haters who want to see RISC-V fail."
The author of this does not really invite a closer reading when he opens like this:
Who says this? He doesn't quote a source so this could be anyone from the implementers of the design to a random Reddit comment. It's a strawman.
There's a lot more detail to the argument, so I'm inclined to be forgiving of this, but it's bad faith rhetoric.
I think the creators of RISC-V regularly say things like that, and though it's probably useful for marketing reasons and to keep morale high, it can also seem unrealistic and disingenuous. "RISC-V is inevitable" is a frequent slogan, and the tech report from 2014 concluded with:
At a panel in 2018, Krste Asanovic was asked where he sees Arm in 10 years, and he said "I look forward to Arm building RISC-V cores."
Openness is a strong positive in favor of RISC-V, enough to allow it to take over the low-end market. But it does seem like, at least so far, the technical limitations of RISC-V may prevent it from being a top contender in the desktop-class market.
Fans like me? OK, I wouldn't say it, but I certainly thought that not that long ago.
Hence the word "fans".
I've noticed this pattern of argument in the past, and my position then stands:
Articulating your side in detail while keeping your opponent shrouded in anonymity is inherently manipulative.
The tech world is full of standards created by committees of experts which wind up looking like the dog’s dinner. The WS-* web services debacle of the 00s springs immediately to mind.
I’m not suggesting this is true of RISV-V but it’s possible.
There is no such thing as bad publicity. The only thing worse than being criticised is not being talked about or thought about at all.
Stroustrup was correct about the two kinds of programming languages.
It's all just a sign of how much we're winning.
The blog preempts this, but it is interesting that about half (but certainly no more) of the issues come from RISC-V not effectively supporting binary reuse across different processors. This definitely takes RISC-V out of contention for desktop computing—where binaries are the de-facto distribution format for software—without adding other standards on top. But it does feel like a defensible choice for a lot of use cases, especially if requiring a recompile can allow you to use simpler and more efficient processors.
Glad that you mention binaries as a de-facto distribution format being relevant to its adoption, because Gentoo seems to be providing good support for it
Some compare it to the times when amd64 was newish and Gentoo had a growing userbase of people atracted to how compatible it was with the it. Portage is already capable of managing the migration with little pain (relatively speaking, of course)
On the embedded front, having a custom chip is 100% the right thing to do and ARM's habit of dictating features when they aren't needed is an anti-feature for many. It's a one-off chip for a platform no one else uses, so saving every penny can reap millions in savings.
This isn't a desirable scenario when the number of users for a platform gets larger, so the RISC-V community created platform specs. This is a mechanism where vendors can coordinate on shared CPU classes with feature baselines. The Qualcomm's of the world will likely have the market share to force their own unique profile - but then it's up to them to provide tooling and upstream support.
The negative consequences of having choices is just the natural result of not having a monoculture. Windows and OS X are monopolies which can dictate the number of flavors available. People complain that "Linux" has too many options, as anyone can create new and slightly incompatible OS and everyone does. But that doesn't make Linux less suitable to create an OS with binary compatibility, as evidenced by vendors like Red Hat.
This increase in the number of variants is just the monopoly powers changing hands. x86 has the same problems between and within Intel, AMD, and various smaller x86 vendors (alive and dead). The mirage provided by proprietary monopoly providers was simpler, for sure, but it also stifled innovation and incentivised marketing driven ISA design.
I appreciate the point about openness. An open spec does very little to make implementations open, unfortunately. If mainstream desktop RISC-V CPUs ever come, there's a 90% chance that they will run closed source UEFI firmware, have hardware that requires executing ACPI bytecode blobs, have undocumented integrated management processors, etc...
And mainstream RISC-V SoCs and SBCs will have exactly the same issues as ARM, where there's not even something like UEFI; all SoCs have their own weird non standard boot process, all peripherals have to be hard coded into a device tree instead of discovered at runtime or provided through a standard interface.
People over-estimate the impact of ARM's closeness and the benefits of RV's openness while under-estimating the impact of Intel and AMD's commitment to making their chips run on standardised platforms which provide way, way more than just an ISA.
I love RV myself, I like that there's an ISA with good compiler support which is both simple enough that I'm able to implement it myself (as I did in Logisim once) and open enough that I'm allowed to do that. But the end user impact is negligible. Is anything, it's worse because ARM has at least made an attempt at standardising an ARM server platform; I don't really trust that the RC foundation will do the same.
Already done and ratified and published.
https://github.com/riscv-non-isa/riscv-server-platform/releases/download/v1.0/riscv-server-platform.pdf
Oh, that's very good!
Though it sounds like they, just like ARM, are treating it as a server-only thing. It should at least be treated as a server+desktop+laptop thing in order for it to be as open as x86 from a user perspective. Ideally, even the new powerful SBCs should have a similar architecture. I don't get why nobody seems to think this stuff matters for consumer
We've now swung back into the "cheap terminals hooked up to expensive compute" era of the 50s/60s. It's easier to extract rents that way.
However not all of the server platform would apply to non-server devices, like the out of bound management interfaces or possibly some virtualization specific instruction set extensions (if there are any, just throwing out the idea)
BRS (Boot and runtime services) specification referenced by the server platform seems like it could apply to a wider range of systems: https://github.com/riscv-non-isa/riscv-brs
Then split it up into layers, one "standard boot process and hardware discovery" layer and one "server management layer" which builds on top of the former.
I think it’s good to critique RISC-V’s design constructively, but the tone of this post made me feel sad and wanting to stop reading.
It’s a free and open design made by passionate people, and everybody is invited to contribute. I don’t think phrases like “embarrassment” and “you can tell the authors are academics” are justified.
Sorry to tone-police here, you’re obviously welcome to rant however you like on a personal blog. I do think the fact that RISC-V exists at all is a miracle, though, and we should be kinder to everyone who made it possible. It’s not being forced on us, people will use it if it works.
That is not what I've heard from people who've tried to contribute but don't agree on everything with the original designers and SiFive.
People have critiqued the design of RISC-V since it started to exist, and it's always been "sod off, we do things the RISC way here!" not "oh, please help us make it better".
Having just gone through this with the CHERI RISC-V base, there are a few things in the RV64Y base that are going to cause a lot of pain down the line, which are there specifically because the RISC-V Architecture Review Board mandated them.
The lack of capability-format agility is going to be painful. Each format is required to be a new base, even though they can compose and a well-designed ABI would not leak them into any software except debuggers (and maybe VM migration between cores of different generations). And, by making it part of the base, they ensure that there are no mechanisms for discovering it during early boot.
Putting ambient-authority sentries in the base is likewise going to cause pain. They were added as a quick and dirty hack in the research ISA to make it possible to test sentries without doing some OS / loader plumbing. CHERIoT removed them because MSRC had a bunch of security concerns about weaknesses in software that would be built on top of them. We can’t use authority-based sentries in the base because no one has done the work to plumb them through in CheriBSD and Linux and ARC refused to allow us to make both extensions and mandate the sensible one later in the profile. So now we’re stuck with the weaker version in the base.
Counter: openSparc and openRISC exist and RV is not a miracle since it doesn’t improve on those significantly.
Do they actually exist, as in, you can go on aliexpress and order a dev board?
They obviously would, if they had the publicity that instead got to RISC-V.
That's a "no" then
Popularising an ISA is a lot of work. RISC-V did the work, it's not their fault others didn't.
Sorry, I didn't mean to imply anything about where the publicity comes from, or how much work it represents. I have no problem admitting it is a ton of work. Just insisting that whoever does that work gets the prize.
Given this, that's a "yes" even if you're right (which you probably are).
RISC-V was an internal project at a university. They only started thinking about turning it into an industry standard when industry folks started asking why they had revised the ISA. So industry people went out and used it for IRL hardware before it was a standard.
It certainly wasn't "publicity" that made the difference here, as they didn't have an advertising budget. openSparc, openRISC, and open MIPS all died because RISC-V was better. MIPS might have had a chance if they had opened up early on, or at least not tried to charge the RISC-V authors to use it.
They were all inferior and the proof is that MIPS is a RISC-V design shop now.
There’s a lot here that is quite misleading.
They didn’t initially have an advertising budget per se, but they did a lot of RISC-V promotion at computer architecture conferences and similar events.
The early adopters were mostly not replacing things like MIPS or SPARC, they were replacing in-house or legacy ISAs for control-plane systems. The performance of these doesn’t matter at all and code density matters only a little bit, but the cost of maintaining an in-house toolchain is huge in comparison to the value. Moving these to something where someone else maintains the compiler back end is a big win.
And that was enough to convince VCs to invest in SiFive and then SiFive (which aimed to be the new Arm) had a big marketing budget.
@dmitrygr claims the gains are marginal. If they are, then this cannot possibly be true.
On the other hand, I have no difficulty believing they all died because RISC-V was percieved to be better. I have read the docs, and as a layman I was impressed. But this is not the first critique of RISC-V I see, and it adds up. Maybe I shouldn't have been so impressed after all.
Some of the creators of those chips disagree. Strongly. The former CTO of Sun certainly thinks RISC-V is an improvement on SPARC.
The severity of the findings more than justify the tone in my opinion.
I think the tone undermines the findings.
Clearly that can't be true. As someone who's not familiar with the topic I don't know which of the other statements in the post are hyperbole or flat out wrong, and the author is not making any effort to present opposing viewpoints fairly so for all I know there could be obvious rebuttals.
It's also just uncool. Even if everything in the post is true it still doesn't make me want to read more from the author much less engage with them.
Honestly I wouldn't know, I'm not put off at all by that tone. Like, at all.
That would be off topic.
I think bringing laypeople up to speed would also be off topic.
I’m not so sure… The author has clearly thought a lot about these problems and their findings could stand up on their own merits.
Obviously it’s okay to vent your frustrations, but the mocking and ridicule sets off alarms in my brain that it’s making up for a weaker argument by diminishing the RISC-V designers. I don’t see evidence that the RISC-V folks have been outright malicious enough to deserve that.
Yeah agreed! I found the technical critique really interesting and insightful, but sometimes it felt a bit mean spirited
This is refreshing.
I am a casual emulator author, and I was surprised with how annoying implementing RISC-V was. Just decoding instructions is such a pain. Of course, it only got worse when I tried to do ARM, and x86 is worse than that.
So would you characterise RISC-V being the easiest to decode of these popular architectures?
PowerPC and Alpha stomp all over it.
You can tell the RISC-V folks never bothered with silly things like actually implementing the system on an FPGA before making decisions. Store Register with Offset is egregiously painful on a small, in-order system as you need a full extra pipeline phase solely for this instruction if your memories are edge clocked. But the only things the RISC-V care at all about are super-pipelined, speculative execution A-Series competitors. Be as good as or better than an M0? Oh, hell, no. Can't be bothered.
They did implement on FPGA, but that’s part of the problem. They had an FPGA implementation and an immature GCC port and used this as the input to a lot of decisions. For example, the article complains about the immmediates scattered all over the place. This was done so that the source operands were known prior to decode, which let you do register fetch before decode. And that is really nice for small in-order cores.
It stops being as useful when you start having floating-point instructions because you know which register to fetch but not which register file to fetch it from.
For superscalar chips, you want to do this post decode because you don’t want false positives in keeping rename registers alive: that will hurt performance more than any decode speedup possibly could.
Even by the time you have dual issue, this property isn’t very useful. But they overfitted for the simple in-order core. All you’re left with is overhead in routing from pulling bits from different parts and running them together. This isn’t an enormous overhead and is normally drowned out by something else.
This also shows up in the C extension. It’s designed so that a simple core can expand every 16-bit instruction to a 32-bit instruction. That lets you add it in the decode stage without any modifications to later stages in the pipeline. And, yes, that does help. In simple, in-order cores.
But for big out-of-order cores, the thing that matters most is the amount of work done per instruction. You have a lot of fixed overheads in fetch, decode, instruction scheduling, register rename, and so on that you want to amortise those costs over larger amounts of work. Rich addressing modes are the obvious win here because doing a bit of arithmetic in a load-store pipeline is basically free, doing two instructions means you calculate the address twice. When this was pointed out early on in RISC-V, Krste kept asserting that instruction fusion (decoding two or more instructions as something that you execute as one) would solve all if those problems. This was never true: instruction fusion is hard, is even harder when trying to fuse instructions across fetch granules, and it means you’ve defined a per-implementation variable-length instruction encoding that compilers have to know about.
The article overstates the cost of decoding variable-length ISAs. I worked on an ISA designed for server cores that used a variable-length encoding and the decoder didn’t show up as a problem in any of the evaluation. And it let us put a load of things in 48-bit instructions, so the 16-bit instruction subset covered well over 50% of dynamic instruction counts. Instructions for system calls and instructions that are usable only in privileged modes were all 48 or 64 bits, so they didn’t eat any of the shorter encoding space.
Yeah, it doesn’t have to be either fixed width or crazypants x86 with nothing in between.
It’s striking that Apple’s and ARM’s fast cores can decode 10 instructions per cycle, but AMD and Intel top out at 4 per cycle (per thread). AMD has an op cache of decoded instructions (that’s a similar size to its undecoded instruction cache) from which it can dispatch 6 per cycle. (ARM does some pre-decoding inside the instruction cache, which it can do when filling the cache because it knows where the instruction boundaries are without having to run the code.)
Which tells me that an excessively complicated instruction encoding creates problems that need some really fancy machinery to deal with, which can be omitted in a core that uses a simpler encoding (if not fixed-width, at least statically decodable). As well as the op cache, hyperthreading is a way to keep a wide core busy when a decoder would otherwise need unreasonably long chains of logic to deal with the sideways dependencies.
I think Stephen Dolan put it best: x86 doesn’t have an instruction decoder, it has an instruction parser. Most variable-length instruction sets do one of two approaches:
This makes it quite easy to have a simple circuit decide where the boundaries are. That’s the most important thing, because it means that you can then do the decode in parallel. It’s still not quite as simple as a fixed-length encoding, though instructions that span cache lines can still be annoying. With very wide decode, fetch granules will span cache lines anyway and if you have a variable length encoding wit 16- to 64-bit instructions then a two-cache-line fetch will give you 32 instructions in the best case, seven in the worst (two-byte aligned start, three eight-byte instructions), but if you have properly tuned the encoding so that 16-byte instructions make up the majority of the dynamic instruction count then you can get wide dispatch with a single line as fetch granule.
The x86 encoding has a bunch of prefixes that each need to be parsed to find the instruction boundary, which makes parsing instructions independently an enormous pain. Modern x86 typically ends up with a complex L1 I-cache that, the first time a cache line is parsed, records the instruction boundaries. It also often has a post-decode cache so that loops don’t need decoding each iteration. And all of that adds power. It doesn’t hurt performance too badly because you get high hit rates in these caches.
Intel's Lion Cove can decode 8 instrs as 8 uOps per cycle and get 12 uOps from the uOp cache (source). Going wider is unlikely to yield too many benefits, the next limitation is probably the branch predictor which can, IIRC, currently predict two taken branches per cycle.
Intel went to 6 with Alder Lake and they're at 8 since Lunar Lake. I don't know how relevant this is though since x86 usually fits more work per instruction so I'd expect them to match Apple's "execution usage per decoder invocation" at lower decoder width. AMD seems to have gone the way of large uOP caches and sizes decode mainly for fill bandwidth. ARM themselves dabbled with decoded uOP caches in their X line. The one thing ARM's fixed-width encoding allows implementations to do is to have a predecoded L0i and move decode from core to cache fill. However I don't think it's worth it to lose variable-width encoding as it's very similar to AMD's approach.
You’re basically describing z/Arch, which is variable width but is surprisingly load-store for a CISC from the 60s. They even made one without memory to memory instructions then too (S/360 model 44).
Which is completely incorrect.
The ISA, the toolchain, and implementations (both FPGA and actual test chips) were co-designed and repeatedly iterated and improved and incompatible changes made.
RISC-V is probably the only major ISA that was iterated with real-world experience before being frozen.
This whole thread makes me super depressed. People complaining about being ignored or booted out from a community and blaming it on that community's technical incompetence or NIMBYism for their social rejection. No self-reflection about why it might be the case that others got tired of (re)explaining things to them.
Did you go beyond FPGA? If not, how did you know you were not over-fitting?
Not me.
Berkeley made multiple test chips (ASICs) in the 2011-2014 period.
SiFive made (and sold) the 32 bit microcontroller FE310 (HiFive1 dev board shipped Dec 2016) and 64 bit Linux-capable FU540 (HiFive Unleashed shipped March 2018) as essentially test chips prior to ratification of the ISA in 2019.
A few thousand FE310 were made, and around 500 FU540.
Could you explain the store issue a bit? As far as I can tell, M0 and RISCV are identical here?
M0:
RISCV (is there really no convenient web index of instructions? TT):
Correction: I misspoke as it was the Load with Offset that did it--it's been a while since I last had to look at the Verilog. For store, you can just dump it to memory on an overlapped stage. For load, you fetch, access the register file, then do an ALU for the offset, and then access memory, and then writeback to the register file. With no offset, you skip the ALU phase and can go straight to access memory. Sorry, I can't edit the original anymore.
The issue doesn't really pop up in full blown custom VLSI design because the 1) cache memory isn't locked to single edges and 2) pipelines are deep in order to do all manner of complicated stuff so you have extra edges to hide the wastage.
Where it bites is when you are designing a straightforward, deterministic, in-order microcontroller with an ASIC (sometimes--although you might get a level-sensitive memory if you get lucky) or an FPGA. Your pipeline stages and memory accesses lock to edges and then you wind up having to drop an entire extra cycle in order to do writeback because of the offset. It's a 25% hit (5 stages instead of 4) for one single instruction and you pay the penalty on every single instruction.
And this is PRECISELY the kind of thing that the RISC-V architects blew straight past because they focused on A-Series type stuff instead of M-series type stuff. The moment you actually put it on an FPGA, it smacks you right in the face.
And, there are also other things that haven't really been touched for real-time work. Go look at what TI did for the PRUs to make hard, real-time stuff work: https://www.ti.com/video/series/pru-training-series.html The PRUs are in-order, deterministic (with caveats) RISC cores that exist along side the high performance main processor. That's the kind of problem that RISC-V is supposed to be good for, but it's not.
The TI datasheets are a really good exemplar of the RISC-V problem. Look at how how much of the datasheets need to be dedicated to everything else in the system that RISC-V doesn't specify.
The ISA is the least of the problem.
Hm, I still don't get your M0 vs RISCV comparison. Both have load with offset, as quoted above?
M0 (3 stage pipeline) and M0+ (2 stage pipeline) are explicitly specified with the RAM access overlap so the Load with Offset isn't a penalty. This makes them a royal PITA to implement on an FPGA, and you almost always see them as hard block synthesized VLSI cores (I won't say soft FPGA versions don't exist--but I have never seen one and certainly not in anything shipped.)
If, however, you don't specify that and part of your proposition is to be a simple, straightforward implementation that makes a good soft IP block, then you wind up with a 5 stage pipeline that pays an entire stage simply to support a single instruction. Now, maybe that's a good tradeoff--Load with Offset is really common (loading constants from an area or offset relative to the stack pointer). Is it 1 in 4 common? It's probably close but it probably doesn't exceed that pretty much ever. However, workloads that don't meet that pay a 20% (or 25% depending on you accounting) performance penalty. Which means supporting Load with Offset is probably not a good tradeoff and, even worse, your implementation gets larger.
Of course, Load with Offset is stupidly simple and obvious on something in a Cortex A-class performance envelope--so nobody notices.
This is the kind of "architecture specification bleeds into implementation" that haunts a lot of RISC-V. The fact that nobody noticed before this shipped is indicative of the fact that nobody pays any attention to the low end (the original articles talks about the problems with interrupts as another exemplar).
Cortex-M1 existed as a separate design off-shot more adapted to FPGAs.
Oooo. Interesting. Thanks for the pointer.
This is the exact opposite of my impression, RV’s design mistakes don’t really matter for a Cortex-M sized core, but are very annoying for a large core.
That's a bold thing to say about the inventors of the RISC architecture.
They did actually implement the system on an FPGA, but only once. A significant amount of the RISC-V architecture is informed by the superscalar, in-order design of boom.
AIUI BOOM was the second design, there was an earlier single-issue in-order design series called Raven which was made on custom silicon https://thechipletter.substack.com/p/risc-v-part-1-origins-and-architecture
That article quotes their design motivation, “a new RISC ISA can be better than its predecessors by learning from their mistakes”, but evidently they repeated the mistakes of “Leaving out too much” and “Allowing current micro-architectural designs to affect the ISA” (the early design was over-fitted for making it easy for undergraduates to write a simple decoder in Chisel as a student project).
PowerPC and Alpha are not in the group of "the popular architectures".
I disagree.
PowerPC, or more accurately POWER as PPC is just one implementation of it, was huge once.
At the same time:
"Was huge once" is not the same as "is popular". It once was among the popular architectures; it's not anymore.
I have to disagree.
The OP is talking about the pros and cons -- mostly cons -- of a CPU architecture, notably a RISC one.
POWER is one of the most successful RISC arches of all time. Arguably it's the first: it started out as the IBM RIOS 7-chip CPU complex, the kit I first used AIX on, and grew from there. It had native ports of everything from multiple proprietary Unixes, to all the BSDs, to Windows NT, a form of OS/2, Windows CE as well, even Novell Netware. It is still sold today, and it is still supported by most enterprise Linux distros today.
When talking about the strengths and weaknesses of different RISC architectures, it is thus a highly relevant comparison, and indeed to fail to include it would be negligent.
To dismiss it because it doesn't sell as well as it used to do is appallingly dismissive.
Unpopular architectures are absolutely interesting to look at from an academic perspective. POWER certainly counts as one of those (despite its famously disastrous bet on big endian). It still doesn't count as one of the popular architectures.
Still no.
You are only considering what is popular now. This is not about now; nobody set time limits here. This is a current architecture, not some historical oddity. Sure, it doesn't sell as many as it once did, but it still sells.
Modern POWER isn't big-endian any more.
I am in the present, yes. What was popular is different from what is popular, much to the dismay of many.
These days, POWER is this weird dual endianness. That's just as bad as being big endian, if not worse.
Seriously, did big endian kill your dog? You never miss a chance to beat that particular horse, and you keep ignoring what everyone who actually uses the platform tells you.
If you have a little endian need, and most current consumers new to the platform will, then you run little. Linux prefers it. Fedora ships it. My Talos II runs it. If you have a legacy big workload, you can still run it, either on the metal, in an LPAR or as a VM. Was IBM just supposed to simply screw over their AIX and i customers, the ones who actually bought and paid for hardware and have contributed to their bottom line?
I have no need for a particular endianness. I have a need for the world to just pick one. If BE was the most prevalent, I would dislike LE architectures, but LE is most prevalent so I dislike BE architectures. POWER's continued support for BE affects me because users of BE POWER will file bug reports agains LE software.
21st century POWER chips can run in both, yes, but pretty much every modern FOSS OS that supports POWER runs in LE mode. The general handle for the OS in Linux and so on is
ppc64le.I'm not a machine-code programmer and never was. I personally don't care. LE makes more sense to me, but as far as modern FOSS coding seems to go, it's over, and LE won.
You seem to be trying to argue 2 conflicting positions here:
POWER doesn't count because it is not a current commercially-successful OS and its history of formerly being popular is irrelevant
POWER today is predominantly little-endian, but that doesn't matter because it used to be predominantly big-endian, then became switchable
Either the historical timeline does matter, or it doesn't. I don't see how you can argue that its history is both important and not important, at once.
Yet, when I express an opinion in favor of writing code which assumes LE, I'm inevitably dogged on by POWER fans who use POWER as an excuse for why code should be written to support both endiannesses. This tells me that "21st century POWER" is still BE-ish enough to be a problem, and must be eradicated so that we can live in a single-endianness world.
That may well be so, but you note I'm not doing it. I really don't care. LE seems more natural to me but I really don't mind.
Power isn't the only bi-endian architecture, ARM (including AArch64), MIPS, SPARC, and now also RISC-V support big-endian as well. There's also z/Architecture (s390x) as big-endian-only (which for several Linux distributions is the only official big-endian arch). I do agree, however, that big endian should cease to exist.
I never hear people use BE ARM or s390x as an argument for why software should support BE. I do hear people use BE POWER as an argument. So that's what draws my ire for the moment.
I think the RISC-V BE support is a huge mistake and pure academic masturbation.
I'm happy to hear we agree. I really don't mind BE, it has slight advantages and LE has slight advantages, picking one is infinitely better than having both; LE is winning so BE should be eradicated.
Why? I personally like to have fast loading for both CRC-32 and ChaCha20. What's the catch?
[Comment removed by author]
The RAD750 is still the chip of choice for deep-space applications. For example, JWST runs on RAD750. As the name suggests, it is compatible with PowerPC 750 binaries. If one is building a brand-new deep-space platform today, one might instead consider the RAD5500, which is binary-compatible with PowerPC e5500.
I was so surprised to see that my old Wii was PPC based, for some reason I assumed it was ARM. I thought about resurrecting it just to have a PPC platform to play with. And then I'm like, who am I kidding, I barely have time to sleep..
I 100% hear that.
But did you know that you can now run Windows NT on a Wii?
https://github.com/Wack0/entii-for-workcubes
No! That seems cursed. Maybe I have to do it. 🤣
:-D
Yes, but way worse than 6502, Z80, and MIPS.
It's been a while, but: 6502 was only easy because of its tiny instruction set and tiny set of registers; it was pretty frustrating for me. Z80 was actually elegant. (I had a Z80 on a card in an Apple ][+ back in the 80s.)
And Motorola is the only company who consistently designed nice ISAs. Unfortunately, I never really got to use theirs.
Z80 was my favourite until I met 68K. Then I met x86 and stopped doing assembly language altogether.
x86 assembly is fun! It's like running blind-folded through a mine-field while being shot repeatedly with paintballs and shat upon by a gaggle of geese. No idea why you didn't like it.
FWIW - I too stopped working in assembly after moving to x86. But that was as much because higher level languages were ok, as it was that x86 assembly was awful.
You owe me a new keyboard!
I still write a fair bit of assembly, but it's mostly Power ISA, which I consider a relatively sane (if sprawling) instruction set, and it's for particular purposes like code generators. Instruction prefixes are creeping in, which I'm not too fond of personally, but I understand the rationale and you can still reason about it as a weird kind of 4-byte opcode.
LOL! It was a long time ago and I was trying to work out how to do 3D graphics from scratch on the Amiga in 68K, I don't remember why but at some point I switched to x86 and I just stopped enjoying it. I often wonder what direction my career would have taken if I'd stuck at the lower level stuff. Not that I can complain, but I read posts by people like @matklad and @david_chisnall and I get envious. I really enjoyed being much closer to the metal.
I am pretty far from metal and can't even write coherent assembly. The extent of my knowledge is basically skimming
Yeah but even your work on TB and in Zig has had me envious, or maybe inspired is the better word. Anyway, you’re much closer to the metal than I am!
Having written decoders and encoders for x86 and AArch64 (and a decoder for RISC-V), I disagree that x86 is worse than ARM -- I'd consider them equivalent. x86 has a fair amount of annoyances (prefixes, register bit extensions and their constraints), but apart from this, the encodings are very homogeneous and the number of different encoding formats is very low. AArch64 makes instruction-length decoding easier (4 bytes, possibly handling movprfx), but the encoding formats are very different per-instruction (different immediate encodings, compact index encodings for vectors, register constraints(!), etc.). Almost every extension adds new encoding formats. AArch64 has also more extensions and more instructions than x86-64.
A conclusion I personally take from the post and the discussion here is to never publish my thoughts on a technical topic in a style as harsh as this, no matter how much I think something is obviously dumb and feel qualified to hold such opinion.
It seems to me that: 1) looking at his background and achievements, OP is more than qualified to talk about this, 2) he makes some good points, which appear correct to me and were not challenged by commenters here, 3) angry presentation style and bad-faith framing makes commenters dismiss all of the above. Sad.
Personally, I like RISC-V. I like the idea of it. Even if the ISA is as awful as OP seems to think, I hope that it is successful despite it. (x86 is).
Wild thought: could Intel save itself by making itself relevant again and build new i860, i960, and Alpha chips, and make the ISAs FOSS?
The i860 was really hard to use for general purpose stuff. It was kind of VLIW like and carried all those problems. The Alpha was hard in both terms of memory models and floating point handling. I have vague memories that debuggers were tricky too. I960 might have been a good path if we had gone down a more lisp machine like route, but honestly we found good ways to handle GC and so forth with general purpose CPUs.
Yeah the Alpha seems very nice for lots of things but has its own share of warts or things that are misdesigns with the advantage of hindsight. The memory model seems like the biggest, but there's also things like treating all integers as signed, apparently kinda weak integer/bit ops in general, etc. Nothing killer, but things that would either need to be fixed with extensions or which would cause similar rants today.
There’s a lot of creative invective here that makes me wish I understood the ISA details better so that I could appreciate it even more.
RISC-V definitely does seem to have some disadvantages relative to ARM64 and amd64.
One advantage, not mentioned in the article, is the developing Chinese foundries will need to pick an architecture for their chips and, for various reasons, licensing amd64 and arm64 may be unattractive. Which leads to loongarch + riscv. I can definitely see risc-v being picked over loongarch.
But there’s RISC-V and RISC-V. The Chinese vendors are realising that you need a bunch of extensions to make RISC-V competitive (see all of the THead extensions). I wouldn’t be surprised if there’s a home-grown Chinese architecture (possibly named Loongarch with a bumped version number) that learns these lessons and provides a better base than RV64I.