[flagged]
RISC-V: They Should Have Known Better
281–290 of 467 posts
Re: RISC-V: They Should Have Known Better
#282Earlier quoted context omitted.
Designing a good 64-bit ISA, much better than RISC-V, is easy. There are thousands of people who could design such an ISA in a couple of weeks, without any AI assistance. The hard part, which has always been the moat of RISC-V, is writing all the required support software for a new ISA, i.e. all the utilities from binutils (assembler, static linker, ELF/DWARF utilities), compiler backends at least for gcc and llvm, d…
The effort to support architectures is now minimal with AI assistance. I made a hobby architecture (based on Intel, but with some changes; I was making an "alternate history" as if a few decisions in the past had been different) and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things. With that said, RISC-V is a nice baseline for de…
The main difficulty in support isn't actually making the changes (which is going to be largely defining various tables and other boilerplate, unless your ISA is really weird and does something unusual), it's in doing all of the politics necessary to get those changes committed upstream.
Re: RISC-V: They Should Have Known Better
#283We are using RISC-V for AI accelerators to great success https://ai.meta.com/blog/meta-mtia-scale-ai-chips-for-billio... RISC-V was a great choice due to being so customizable and extensible.
He addresses this use case in the article.
Re: RISC-V: They Should Have Known Better
#284Earlier quoted context omitted.
Not a bug, just not optimized. Because I think there's a csr to read it the fpu is dirty but... That requires csr extension. It would also increase jitter, which in some cases is more important. At best it should be still there as an option, but also optionally improved
Fair enough. It's a performance issue but not a functional correctness issue. > Because I think there's a csr to read it the fpu is dirty but... That requires csr extension Yes, and they already unconditionally read that CSR :-) The "CSR extension" is an almost 100% theoretical concern. It was the spec authors being defensive in case the privileged ISA was so flawed they had to throw it out in future, while keeping t…
You know what, you're right. I was thinking of the timer option. I don't think you can turn off the csr functions on that core. But I've gotten into trouble turning off the timer
Re: RISC-V: They Should Have Known Better
#285> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something.
This is not the only reason to use a microcontroller or 75% of microcontroller vendor (e.g. STM) offerings would have no customers. Not everyone has custom IP that does all the work either, that’s actually fairly rare. It’s odd to pigeonhole microcontrollers like this just to go on a fairly lengthy rant about interrupt latency as if that somehow makes RISC-V unsuitable to what is an incredibly diverse application space. Maybe the rest of their post has better arguments, but I’m not impressed enough by the first one to keep reading.
Re: RISC-V: They Should Have Known Better
#286RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…
> RISC-V is .. fine. Yeah, so was 8051 and it sucked too :-). I appreciated having this rant all in one place. Ranting against bad architecture is always cathartic and absolutely useless since the people who built and now champion the bad architecture are invested so one's rant simply irritates them. And like the parent comment here, I too find RISC-V "useful" in that it has sufficient tooling to make most everything…
> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are
To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?)
RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS.
Far from optimal, obviously flawed, and could change human society for the better. Ubiquity is inevitable.
Re: RISC-V: They Should Have Known Better
#287Random minor-ish notes: - A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd…
Some more:
> The spec says that bit must be zero, and yet no encoding uses the space opened up by that bit being one.
The spec says "the code points with shamt[5]=1 are designated for custom extensions.", so the space is specifically reserved for custom vendor extensions.
So, if I wanted to add a custom "dzaima.c.clear_top_n_bits rd, imm5" instruction, that's space I could safely put it in, knowing that no future standard instruction will be added there that I may regret overlapping. So while that space goes unused in the standard, its existence helps with the overlapping encoding problem!
> For I-type instructions, bit 1 [...], bit 11
Of course, that's cherry-picking two of the 25% of bits that have multiple positions they come from, and specifically 11 as it's the worst one. Full stats:
1 position: 24 bits: (everything that's not listed below)
2 positions: 7 bits: 0, 1, 2, 3, 4, 12, 20
3 positions: 1 bits: 11 (the single worst case)
Obligatory note is that some of the funkiness is to place the sign-extended bit in the same bit position, so some saved muxes from that.
Now, I am a "software person who's never written verilog", but I highly doubt a 3:1 mux is as cheap as a 2:1 mux in silicon, so even if you always need to merge in the sign bit, reducing the number of cases is still beneficial.
Compressed does make it a ton more ugly though (combining both 32-bit and 16-bit instruction encodings, placing the 16-bit ones in the low 16 bits):
1 position: 13 bits
2 positions: 7 bits: 10, 13, 14, 15, 16, 17, 20
3 positions: 4 bits: 3, 4, 9, 12
4 positions: 5 bits: 0, 1, 2, 5, 11
5 positions: 3 bits: 6, 7, 8
tbz Xt, #imm, #relS*4 imm:1|0110110|imm:5 | relS:14 |Rt
lsl Xd, Xn, #n 1 1010011|01|immr:6|imms:6|Rn|Rd
Re: RISC-V: They Should Have Known Better
#288It's clear that RISC-V started as an academic exercise (albeit from a group with esteemed credentials) and they had to bolt on these hacks to make it work in industry. Sad.
ARM was also rooted in an academic exercise. A lot of the drawbacks for modern ARM PC platforms stem from the aversion to actually advanced features like SVE/SVE2 and UEFI.
It's sad, but it was also wildly successful. RISC-V has already replaced ARM in highly-custom embedded spaces like Nvidia's GPU controllers, and it likely won't stop unless ARM finally changes their tune vis-a-vis licensing.
Re: RISC-V: They Should Have Known Better
#289Earlier quoted context omitted.
The effort to support architectures is now minimal with AI assistance. I made a hobby architecture (based on Intel, but with some changes; I was making an "alternate history" as if a few decisions in the past had been different) and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things. With that said, RISC-V is a nice baseline for de…
The main difficulty in support isn't actually making the changes (which is going to be largely defining various tables and other boilerplate, unless your ISA is really weird and does something unusual), it's in doing all of the politics necessary to get those changes committed upstream.
Maintining this type of long time fork is the kind of mind numbing, tedious thing LLMs are actually exceptionally good at. I did some backend work on Lean4 compiler and then they switched out parts of the codegen, it took Codex less than an hour to recover the feature set I had implemented but on the new backend.
Re: RISC-V: They Should Have Known Better
#290> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something. This is not the only reason to use a microcontroller or 75% of mic…
This is a "microcontroller core", not a "microcontroller".
We're talking "deep embedded" applications - where an ASIC is designed for a very specific purpose, and that design just so happens to call for a programmable CPU core to be included in it.
This is the kind of design that lives in your keyboard, your mouse, your USB stick, your USB hub, your HDD, your SSD, your eMMC chip, your memory card and more. Remember: you're never more than 3 meters away from an 8051 core.
I do agree that most of this piece is nitpicking - poking at ultra low level things that are largely irrelevant to the tried and true "deep embedded" exercise of Just Ship It.
No one really gives a shit if an operation takes one instructions or two, or which instruction sets are consistently present in different cores. What "deep embedded" people give a shit about is not having to work with ancient 8051 tooling and 8 bit ALUs and memory banked 64kb spaces while writing code for the one core they happen to actually have. And RISC-V got that. The piece actually agrees with that sentiment.