The RISC-V specs insist that this is important for simplifying high performance designs, because a flag register is a single piece of shared state that instructions are constantly (and often inadvertently!) touching. This necessarily introduces hazards and serialization.
I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.
By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.
And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns.
Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed.
RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space.
Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)
You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state.
Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"
Without knowing it, you're thinking at neither high nor low level. You've accepted at face value claims made by RISC-V architects about how to design an ISA for low level embedded controllers, but they weren't actual experts in that field. Instead, they were largely academics.
When you read their stuff, they're constantly overestimating the value of ultra-minimalist CPU designs in the modern context. In fact, they often show little understanding of the real impact of ISA design decisions on implementation complexity, so some of their decisions don't even make sense as minimalist decisions.
To expand on the low value of minimalism: even in trailing edge process nodes, if you're designing something on the scale of a simple single-issue in-order 32-bit RISC core targeting no particular frequency, gates are essentially free. The RISC-V guys are badly out of touch. If minimum gate count mattered as much as they think it does, there would still be a thriving market for 8-bit microcontrollers. Instead, they're steadily losing market share to 32-bitters, even in applications where an 8-bit µC would be more than enough. It's not the 1980s, you don't have to struggle to fit a featureful 32-bit core into a single die anymore, but they're hellbent on relitigating that era's debates.
If the spec was only arguing that avoiding flags allowed for simpler implementation of minimal in-order pipelines... I might actually agree with it.
But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.
I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.
I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.
> Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.
I agree in general, we do however see that the cost of flags isn't free by the fact that most modern Arm processors only support ADCS on half of the ALUs supporting ADD.
If it was free/negligible, you would see ADCS support on all ALUs.
Yeah... I more mean that it shouldn't add much design and verification complexity. You are mostly just reusing mechanisms you already need. Nor should it negatively impact FMAX. And I suspect the area cost is reasonably low (but not zero)
The lack of flags on those ALUs probably tells us more about the lengths CPU designers will go for reasonably small savings than it tells us about how much flags actually costs. And it's probably more of a "our metrics never gave us enough justification to even consider adding flags to the extra three ALUs" than "we considered it, but the cost was too high".
Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated).
I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.
Damn, I remember I worked through the whole damn thing some years ago when I read this article for the first time, and it didn't hold up to it's claim. I was actually contemplating to do a write-up, but it wasn't really important to me so I didn't. Seeing the same article re-appear on HN for the second time now I really wish that I did. Unfortunately I've forgotten the details by now.
> Nerd culture used to be a stepping stone for many curious people—they might start with science fiction, fantasy, or comics, then branch into philosophy, literature, history, and art. Now that nerd culture has become mainstream and endlessly rewarding on its own, more people stay immersed in fictional worlds instead of expanding into broader intellectual pursuits.
It’s an interesting idea. I’m skeptical though. And I’m not sure if there’s any way to measure this I would guess there’s more intellectuals than there’s ever been before due to increasing populations and literary literacy rates and access.
I've been to Japan - the first cheap buy-and-nuke-at-home ramen from the konbini around the corner I ate there completely blew me away (†)! It was decisively better than what I would realistically expect to get in a restaurant in the west. I don't know how they do it, but I learned never to underestimate the Japanese people’s dedication to their craft.
(†) For the curious, it was chāshū ramen.
Edit: To avoid confusion, I do not mean instant ramen, but a plastic bowl of chilled, pre-prepared take away ramen soup.
That impressed me too, but I brush it off to hunger and other biases.
> chāshū ramen.
Chashu is just name for pork theh put in soup. Main charecterization is type of broth - tonkotsu is the hardest to pull off as it requires 8 hours of boiling bones (but I’ve seen ready made broth to buy so I suspect most shops use that). Miso one is pretty trivial to make at home. I guess not many know this but one type of tare (condiment you put in ramen) is literally charred garlic (30 minutes in oil or so, then blend it). Once you learn this you’ll always spot it (typically in tonkotsu).
As for western shops I agree they are mostly meh, some very much so. Even decent ones you are more of a buying Japanese ramen experience than the food itself lol (I succumb to it myself).
I think the boiling is closer to 18 hours. I do a pretty good one in about 5 in my instant pot, though.
Another big problem with getting a "ramen" in a random western restaurant is noodles. If they don't make them themselves, the dry shelf stable stuff is just not good (at least what I can find in my EU country). As I was slowly upping my ramen game at home, the single biggest difference in quality was when I started making my own noodles.
I suppose if a shop markets itself as a ramen shop, you have a chance of getting a decent bowl. Most of the "asian" or even "japanese" restaurants in my city are places where they add cream to tonkotsu to make it white...
When I look at the recently (say, last 1-2 years) published practical improvements in the LM space, they're not even close to what the Chinese are publishing.
reply