[adrian_b]

RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed.

Any competent computer engineer can design a much better ISA than RISC-V.

The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compilers for various programming languages etc. requires a huge amount of work, of many man-years.

The reason why everybody who uses neither x86 nor Arm tends to use RISC-V is in order to reuse the existing software toolchains, and not because the RISC-V ISA would be any good. The advantage of being able to use already existing software toolchains is so great that it ensures the use of RISC-V regardless how bad it is in comparison with something like Aarch64.

The Intel ISA, especially its earlier versions, has also been one of the ugliest ISAs, even if it seems polished when compared to RISC-V. It would be sad if after so many decades during which the Intel/AMD ISA has displaced other better ISAs, it would eventually be replaced by something even worse.

As one of the main examples of why RISC-V sucks, I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty, unless the ISA is clearly declared as being a toy ISA, unsuitable for practical applications.

[h3lp]

   Any competent computer engineer can design a much better ISA than RISC-V.

Hello, my fellow bitter old man! I have to respectfully disagree, though. Firstly, RISC-V was actually designed by competent academic designers with four preceding RISC projects under their belt. The tenet of RISC philosophy is that the ISA is designed by careful measurement and simulation: the decisions are not supposed to be based on gut feeling or familiarity, but on optimizing the choices, which they arguably did.

Specifically, about detecting the overflow: the familiar, classic approach of a hardware overflow (V) flag is well known to be suboptimal, because of its effect on speculative and OoO implementations. RISC-V has enough primitives to handle an explicit overflow checking, and they are consistent with performance techniques such as branch prediction and macro fusing, to the point of having asymptotically vanishing cost--there can be no performance penalty. Even more so, the RISC-V code that does NOT care about overflow can completely ignore these checks.

[pseudohadamard]

  I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty

Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard, could leave out overflow detection. I'm not saying it's a good idea, in fact it's complete and utter braindamage, but I can see where they got it from.

[snvzz]

The premise that the ISA has no means for detecting integer overflow is false.

This is explicitly documented in the spec, even.

e.g.

    add   t2, t0, t1
    bltu  t2, t0, overflow

The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.

[rep_lodsb]

That only works for unsigned integers.

[camel-cdr]

Signend 64-bit is the worst case. When I tried to enable overflow checking thr overhead of RISC-V and Arm was comparable: https://news.ycombinator.com/item?id=46588159#46668916

[snvzz]

Refer to the spec for the official idioms to handle every case.

[rep_lodsb]

Yes, you can detect signed overflow that way, but it's a lot more instructions so it won't be used in practice.

The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

[snvzz]

>but it's a lot more instructions so it won't be used in practice.

It will be used when it needs to be handled. e.g. where elsewhere, an exception would actually handle it. Which is seldom the case.

More instructions doesn't mean slower, either. Superscalar machines have a hard time keeping themselves busy, and this is an easily parallelizable task.

>The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

Refer to "Computer Architecture: A Quantitative Approach" by by John L. Hennessy and David A. Patterson, for the actual methodology followed.

[fragmede]

What does that mean in a world where writing software just got a few orders of magnitude cheaper? An Andrew Huang could create a new ISA replete with everything and get it done.

[kode-targz]

It didn't though. Not good software at least. AI (which is what I'm guessing you're referring to here) is simply incapable of writing such mission -critical low-level code, especially for a niche and/or brand new ISA. It simply can't. It has nothing to plagiarize from, contrary to the billions of lines of JavaScript and python it has access to. This kind of work can most definitely be AI-assisted, but my estimate is that the time gained would be minimal. An LLM is able to write some functional arduino code, maybe even some semi-functional bare-metal esp32 code, but nothing deeper than that.