this just isn't true. both addition and multiplication can check for overflow in <2 instructions.
First, the code claims to be returning "unsigned long" from each of these functions, but the value will only ever be 0 or 1 (see [1]). The code is actually throwing away the result and just returning whether overflow occurred. If we take unsigned long *c as another argument to the function, so that we actually keep the result, we end up having to issue an extra instruction for multiplication (see [2]; I'm ignoring the sd instruction since it is simply there to dereference the *c pointer and wouldn't exist if the function got inlined).
Second, this is just unsigned overflow detection. If we do signed overflow detection, now we're up to 5 instructions for add and mul (see [3]). Considering that this is the bigger challenge, it compares quite unfavorably to architectures where this is just 2 instructions: the operation itself and a branch against a condition flag.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
It's just a bizarre design choice. I understand wanting to get rid of condition flags, but not replacing them with nothing at all.
EDIT: It seems the same choice was made by MIPS, which is a clear inspiration for RISC-V.
1. 64 bit signed math is a lot less overflow vulnerable than the 16/32 bit math that was extremely common 20 years ago
2. For the BigInt use-case, the Riscv design is pretty sensible since you want the top bits, not just presence of overflow
3. You can do integer operations on the FPU (using the inexact flag for detecting if rounding occurred).
4. Adding overflow detecting instructions can easily be done in an extension in the future if desired.
Read the RISC-V documentation to see that you need at least 3 instructions.
For addition, overflow happens when you add 2 positive numbers and the result is negative, or when you add 2 negative numbers and the result is positive.
After using an instruction to do the addition, how can you detect this complex condition with a single instruction in the impoverished RISC-V ISA?
EDIT: Someone has downvoted this, presumably because I have not been polite enough.
That may be true, but I consider much more impolite the kind of misleading false information that has been written by the poster to whom I have replied. It is difficult to read that kind of b*s*t and be cool about it.
Most languages don't care about integer overflow. Your typical C program will happily wrap around.
If I really want to detect overflow, I can do this:
add t0, a0, a1
blt t0, a0, overflow
The correct sequence of instructions is given in the RISC-V documentation and it needs more instructions.
"Integer overflow" means "overflow in operations with signed integers". It does not mean "overflow in operations with non-negative integers". The latter is normally referred as "carry".
The 2 instructions given above detect carry, not overflow.
Carry is needed for multi-word operations, and these are also painful on RISC-V, but overflow detection is required much more frequently, i.e. it is needed at any arithmetic operation, unless it can be proven by static program analysis that overflow is impossible at that operation.
And what did I find? Yep that code is right from the manual for unsigned integer overflow.
For signed addition if you know one of the signs (eg it’s a compile time constant) the manual says
addi t0, t1, +imm
blt t0, t1, overflow
add t0, t1, t2
slti t3, t2, 0
slt t4, t0, t1
bne t3, t4, overflow
add t0, t1, t2
addw t3, t1, t2
bne t0, t3, overflow add eax, ecx
jo overflowCode size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.
Historically RISC instructions were 1:1 with CPU operations, in theory allowing the compiler to better optimise logic, but this isn't really true anymore. High performance ARM CPUs use µOPs and macro-op fusion, though not to the extent of x86 CPUs.
This document from ARM has some details on how they use micro-ops, https://developer.arm.com/documentation/102160/latest
Except it isn't. Code isn't one single pattern repeating again and again; on large enough bodies of code, RISC-V is the most dense, and it's not even close.
CISC ISAs were historically designed for humans writing assembly so they have single instructions with complex behaviour and consequently very high instruction density.
RISC was designed to eliminate the complex decoding logic and replace it with compiler logic, using higher throughput from the much reduced decoding logic (or in some cases no decoding at all) to offset the increased number of instructions. Also the transistors that were used for decoding could be used for additional ALUs to increase parallelism.
So RISC by its nature is more verbose.
Does the tradeoff still make sense? Depends who you ask.
Currently, RISC-V holds the crown of code density in both 64 and 32 bit.
On 32bit, thumb2 is a little behind. On 64bit, x86-64 is not even close, and ARMv8/v9 are even worse.
"Maybe if I keep repeating it, it'll be true."
It's easy to believe you're replying to something that has an element of hyperbole.
It's hard to believe "just do 2x as many instructions" and "ehhh who cares [i.e. your typical C program doesn't check for overflow]", coupled to a seemingly self-conscious repetition of a quip from the television series Chernobyl that is meant to reference sticking your head in the sand, retire the issue from discussion.
The sequence of instructions given above is incorrect, it does not detect integer overflow (i.e. signed integer overflow). It detects carry, which is something else.
The correct sequence, which can be found in the official RISC-V documentation, requires more instructions.
Not checking for overflow in C programs is a serious mistake. All decent C compilers have compilation options for enabling checking for overflow. Such options should always be used, with the exception of the functions that have been analyzed carefully by the programmer and the conclusion has been that integer overflow cannot happen.
For example with operations involving counters or indices, overflow cannot normally happen, so in such places overflow checking may be disabled.
Since my previous attempt to measure the impact of trap on signed overflow didn't seem to have moved your position one bit, I thought I'd give it a go in the most representable way I could think of:
I build the same version of clang on a x86, aarch64 and RISC-V system using clang. Then I build another version with the `-ftrapv` flag enabled and compared the compiletimes of compiling programs using these clang builds running on real hardware:
runtime: x86 | aarch64 | RISC-V (RVA23)
Zen1 | A78 A55* | X100 A100 !!! all cores clocked to about 2.2GHz, Zen1 can reach almost 4GHz
clang A: 3.609±0.078 | 4.209±0.050 9.390±0.029 | 5.465±0.070 11.559±0.020
clang-ftrapv A: 3.613±0.118 | 4.290±0.050 9.418±0.056 | 5.448±0.060 11.579±0.030
clang B: 8.948±0.100 | 10.983±0.188 22.827±0.016 | 13.556±0.016 28.682±0.023
clang-ftrapv B: 8.960±0.125 | 11.099±0.294 22.802±0.039 | 13.511±0.018 28.741±0.050
Suprizinglt the -ftrapv overhead seems the highest on the Cortex-A78. My guess is that this because clang generates a seperate brk with unique immediate for every overflow check, while on RISC-V it always branches to one unimp per function.
Please tell me if you have a better suggestion for measuring the real world impact.
Or heck, give me some artificial worst case code. That would also be an interesting data point.
Notes:
* The format is mean±variance
* Spacemit X100 is a Cortex-A76 like OoO RISC-V core and A100 an in-order RISC-V core.
* I tried to clock all of the cores to the same frequency of about 2.2GHz. *Except for the A55, which ran at 1.8GHz, but I linearly scaled the results.
* Program A was the chibicc (8K loc) compiler and program B microjs (30K loc).
binary size:
x86 aarch64 RISC-V
clang: 212807768 216633784 195231816
clang-ftrapv: 212859280 216737608 195419512
increase: 0.24% 0.047% 0.09%> Maybe looking at libgmp could be interesting, though I suspect absolute numbers will not be meaningful, and there's no baseline to compare them to.
Realistically, nobody cares about BigInt addition performance, considering there is no GMP implementarion using SIMD, or even any using dependency breaking to get beyond 64-bit per cycle.
I whipped up a quick AVX-512 implementation that was 2x faster than libgmp on Zen4 (which has 256-bit SIMD ALUs). On RISC-V you'd just use RVV to do BigInt stuff.
Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse.
Detecting integer overflow in hardware is extremely cheap, its cost is absolutely negligible. On the other hand, detecting integer overflow in software is extremely expensive, increasing both the program size and the execution time considerably, because each arithmetic operation must be replaced by multiple operations.
Because of the unacceptable cost, normal RISC-V programs choose to ignore the risk of overflows, which makes them unreliable.
The highest performance implementations of RISC-V from previous years were forced to introduce custom extensions for indexed addressing, but those used inefficient encodings, because something like indexed addressing must be in the base ISA, not in an extension.