[snvzz]

The usual RISC-V FUD points. It gets boring.

>It has a soup of wacky opcodes to optimize corner cases

OK, go ahead and name one (1) such opcode. I'll wait.

>obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!).

Yes, these extensions are harmful, and that's why they're obscure and vendor-specific.

RISC-V considers pros and cons, evaluates across use cases, and weights everything when considering whether to accept something into the standard specs.

Simplicity itself is valuable; that is at the core of RISC. So the default is to reject. A strong argument needs to be made to justify adding anything.

[codedokode]

RISC-V ISA is very inconsistent. For example, for addition with checked overflow the spec says that there is no need for such instruction as it can be implemented "cheaply" in four instructions. But at the same time they have fused multiply-add which is only needed for matrix multiplication (i.e. only for scientific software), which is difficult to implement (it needs to read 3 registers at once), and which can be easily replaced with two separate instructions.

[brucehoult]

Fused floating point multiply-add with a single rounding from the infinite-precision answer is required by the IEEE 754-2008 floating point standard.

You don't get a choice in the matter.

> can be easily replaced with two separate instructions

It can't. You will get different answers.

RISC-V allows you to choose a CPU without floating point instructions. But if you choose to have an FPU then you get multipy-add. Yes, it needs to read three registers, which is expensive. It is also the most common instruction in any floating point calculation, so that expensive three port register file gets used constantly.

Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). On RISC-V you need four instructions only if the operands are full register size and you don't know anything about either operand. If you know the sign of one operand then the cost reduces to one extra instruction.

[skissane]

> Checking overflow for addition on the other hand is something that is very seldom used (on any CPU)

I think a lot of that is due to the popularity of C, and the fact that C has no built-in support for overflow checking. In some alternate timeline in which C had that feature (or a different language which had that feature took C's place), I suspect it would have been used a fair bit more often.

Well C23 finally adds checked arithmetic, in <stdckdint.h>. But, it took until 2023 to do it, what if it had been there 20, 30, 40 years ago? Very little software supports it yet anyway.

And it isn't using the same syntax as standard arithmetic. Instead of `c = a + b`, you have to do `ckd_add(&c, a, b)`. That isn't going to encourage people to use it.

[codedokode]

Yes the ugliness of the syntax for checked addition overweighs benefits like better accuracy and security from using it.

[codedokode]

> Checking overflow for addition on the other hand is something that is very seldom used (on any CPU).

I believe you are wrong. Almost every addition used in software should be a proper addition, not addition module 2^32 or 2^64. For example, if you want to calculate total for customer's order, you want proper addition, not a remainder after division by 2^32. Or if you are calculating a number of visitors of a website, again, you need the correct number.

Addition modulo N is used only in niche cases like cryptography.

In my opinion, it is wrapping addition which is seldomly used. I can't remember last time when I needed it. So it is surprising that RISC-V makes rarely used operation take less instructions than more popular one.

You might argue, that some poorly designed ancient languages have '+' operator to perform wrapping addition, however that is only because they are poorly designed, not because users want such method of addition. For comparison, a properly designed language, Swift has non-wrapping addition.

[defrost]

> Addition modulo N is used only in niche cases like cryptography.

... and niche cases like GIS location computations on a spherical planet and any form of engineering | physics mesh computation.

It's inescapable when you peer into the guts of any earth based modelling from satellte data .. something that happens on a daily terrabyte scale.

[ghusbands]

Even if there are some more cases, the basic point is still true: The majority of additions don't warrant word-size wrapping and it has been a source of many, many bugs.

[rcxdude]

Which is almost never wrapping at a power of two, unless you scale your coordinate system to optimise it.

[defrost]

The quote I responded to was:

> Addition modulo N is used only in niche cases ...

and not modulo 2^N.

The point that I would make is that general purpose CPU's doing general everday tasks such as https connections, secure transfers, GIS mapping, etc are doing a great many more modulo operations than acknowledged above.

[tsukikage]

> Checking overflow for addition on the other hand is something that is very seldom used

Arithmetic on numbers larger than your word size. Poster child: crypto. It's 2023 and crypto is not rare. This post cannot get from me to you without crypto in the datapath.

[codedokode]

Also, here is a list of languages where '+' operator doesn't overflow: PHP, Python, Javascript and Swift. JS doesn't even have wrapping addition, and nobody seems to be unhappy about that.

[tsukikage]

Python has abritrary integer size. However, it runs on machines with a fixed word size. This means internally it has to perform all the usual tasks involved in arithmetic on numbers larger than the machine word size, just like back in the 70s: overflow checking, explicit propagation of carries, taking great care with magnitudes of inputs etc all over the dang place. Like, seriously, everywhere. Take a look: https://github.com/python/cpython/blob/main/Objects/longobje...

I certainly hope for at least some of that code the compiler ends up making use of adc and family, otherwise it's gonna be utterly miserable. It's great that the language is hiding that complexity from the programmer, but it's a big mistake to imply that this means it does not happen at all.

Javascript stores its "integers" in the mantissa of a floating point NaN and makes no attempt whatsoever to hide the implications of that decision from the unsuspecting developer; and good grief that leads to an incredible amount of pain and suffering.

[brucehoult]

JS doesn't even have integers. The only numeric type is double precision floating point. If you get to 2^53 then you start to lose LSBs -- that's a lower limit than integers wrapping on a 64 bit ISA (at 2^63 or 2^64).

[saagarjha]

I’d be bored too if I showed up in RISC-V threads to read “FUD” into any comment that doesn’t immediately praise every aspect of the architecture.