Hacker News Reader

Comment by davidkwast | Hacker News Reader

RISC-V can be essential for this open future

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.

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.

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.

  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.

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.

That only works for unsigned integers.

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

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.

>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.

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

   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.

As far as I understand RISC-V has the same lack of standardization that ARM has, no?

If anything, worse - there's much wider variety in the set of CPU extensions available.

RISV-V is messy but for good reason, with real standards, although lots of them, which can be hard to keep track of.

X86 is de-facto standardized by vendor fiat.

ARM is in an unfortunate middle ground.

RISC-V is the ARM mess taken to extremes. From TFA:

  It’s a crapshoot. That’s why whenever anyone recommends a certain cool Arm motherboard or mini PC, the first thing you have to figure out is what its software support situation is like. Does the OEM provide blessed Linux images? If so, do they offer more than an outdated Ubuntu build? Have they made any update promises?

Almost every ARM board I've got is running ancient kernel images that were out of date even when they were released and haven't got any newer since then, but that's positively great compared to the RISC-V situation where you feel like you're taking your life into your hands every time you try and update it. The last update I did, to a popular widely-used board, took close to a full day to progressively reflash different levels of boot loaders and kernel images and whatnot, repartition the MTD for each reflash, hack around hardware and boot params via the serial interface through trial-and-error, and slowly work my way up to a current already out-of-date firmware and kernel config.

I really hate to like x86 but I know that when I set up an embedded x86 device it's flash, apt-get update/upgrade, and I've got the latest stuff running and supported.

Reply on news.ycombinator.com