Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time. Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cyc…
> The market can sort it out for themselves Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.
RISC-V: They Should Have Known Better
41–50 of 467 posts
Re: RISC-V: They Should Have Known Better
#42Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time. Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cyc…
He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.
Re: RISC-V: They Should Have Known Better
#431. 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 a simple implementation.
I think Dmitry's points are largely on-target, though I have filed my usual statutory complaint that every rant that includes a bitfield diagram for the RISC-V J format should accompany it with a similar diagram for the Arm T32 BL encoding.
Re: RISC-V: They Should Have Known Better
#44Earlier quoted context omitted.
You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, n…
I don't think I've read a more "doesn't actually know anything about how software is produced, but with absolute confidence knows everything about it" post in a very long time.
Re: RISC-V: They Should Have Known Better
#45Re: RISC-V: They Should Have Known Better
#46Re: RISC-V: They Should Have Known Better
#47The reality? The fastest "available" RISC-V CPUs don't match the best chips in terms of speed, power consumption, or die area. "available" obviously means the chips that have been released to the public and can be independently benchmarked.
I do think that is okay, however I also think that those involved with RISC-V aren't helping much, and current attempts at standardizing seem to be just creating a bigger problem.
That being said, RISC-V does seem to perform well in specific niches.
Re: RISC-V: They Should Have Known Better
#48I think a lot of this criticism is completely true. However it's also overblown. I do think the ISA matters, but little mistakes like these definitely don't matter enough to preclude making M-series class chips. The reason it hasn't happened yet is simply time. It takes a really really long time to build up to that level of performance. They've definitely gone overboard on the optionality stuff though. I don't think…
1) power
2) performance
3) die area
SOME chip designs also care about a 4th:
4) die area.
NO design has the best of all...it is impossible since you have to trade 1 for another. The reason x86 has been dominate for so long is that is strikes a good balance across all areas, especially #4. A good balance is what you need for a good chip.
EDIT: oh and you can't beat the system I mentioned above. The laws of physics are the reason why.