[adrian_b]

RISC-V has obviously been initially designed with the only purpose of being extremely simple to implement, simple enough to be implementable by students.

Nothing else can justify the weird choices made in designing RISC-V.

The idea to use RISC-V in actually useful devices must have come only after the initial design and for this purpose the only advantage of RISC-V versus designing some proprietary CPU core is that for RISC-V there already exists a significant amount of tools for software development, i.e. linkers, assemblers, compilers, debuggers, a few optimized libraries etc.

This advantage of RISC-V is extremely important, because developing compilers and all the other required software tools for any new ISA requires much more work and resources than the hardware design of a CPU core implementing it.

However, it is sad that the first ISA with a permissive license allowing it to be used by everyone everywhere has been one so bad as RISC-V.

It is absurd to claim that the target of RISC-V is to 'be an ISA for everything', when it does not even have adequate means for detecting integer overflow, a feature that existed even in much smaller ancient 8-bit microprocessors, like Motorola MC6800 (1974) and Zilog Z80 (1976).

Startups choose RISC-V because it is a fashionable buzzword good for pleasing possible investors and because their team does not include anyone with experience in low-level assembly programming or compiler back-end implementation, the only people who can assess the quality of an ISA.

[Footpost]

The reasoning for this choice in the base ISA is discussed in the RISCV ISA manual, Section 2.4 on "Integer Computational Instructions" [1]. Given that RISCV is a modular ISA, it should be possible in principle to have suitable ISA extensions that do integer overflow detection. Maybe the absence of such an extension in 2025 indicates that this is not a pressing need for many RISC-V users?

[1] https://lists.riscv.org/g/tech-unprivileged/attachment/535/0...

[snvzz]

While very convenient to quickly link some ancient draft spec, let's try and stick to the actual ratified specifications[0].

Of course, the rationale is still there in section 2.4 of the current (20250508) ratified version of The RISC-V Instruction Set Manual Volume I: Unprivileged ISA.

0. https://riscv.org/specifications/ratified/

[panick21_]

You should learn about the history of RISC-V. RISC-V was initially designed to do research on advanced instructions architectures, like Vectors. So writing 64 bit chips with large vector engines was literally the initial design goal. And they deliberately went threw all historical bad ideas that were known to cause issues in out-of-order designs because the knew they wanted to do research on that as well. So its quite simply a historically well documented fact.

But they needed a simple base ISA that they could extend in different ways because different people planned on doing different kind of research on top.

When they then realized their was a need for a permissive license ISA that would be used be people outside of Berkley, like that they formulated a clear goal that is in all their early presentations, and it was "be the ISA for everything".

> when it does not even have adequate means for detecting integer overflow

Seems adequate for 1000s of companies who use RISC-V.

There are pros and cons of not having it, and the argument that 'X other design had feature Y' isn't an actual argument. Nobody has ever denied that they could have added that, its simply because they didn't want to.

> because it is a fashionable buzzword

I'm sure you are so much smarter then Jim Keller and David Dizel ...