4 ms·

Because the other commenter wasn’t posting the actual answer, I went to find the documentation about checking for integer overflow and it’s right here https://d

Because the other commenter wasn’t posting the actual answer, I went to find the documentation about checking for integer overflow and it’s right here https://docs.riscv.org/reference/isa/unpriv/rv32.html#2-1-4-integer-computational-instructions https://docs.riscv.org/reference/isa/unpriv/rv32.html#2-1-4-... 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 But the general case for signed addition if you need to check for overflow and don’t have knowledge of the signs add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow From what I’ve read most native compiled code doesn’t really check for overflows in optimised builds, but this is more of an issue for JavaScript et al where they may detect the overflow and switch the underlying type? I’m definitely no expert on this.

userbinator 7mo ago
Contrast with x86: add eax, ecx jo overflow
- rwmj 7mo ago
  Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code 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.
  - userbinator 7mo ago
    I thought the main distinction of RISC-V (and MIPS before it, along with RISCs in general) is that the instructions are themselves of equivalent complexity (or lack thereof) as x86 uops. E.g x86 can add a register to memory, which splits into 3 load / add / store uops, but a RISC would execute those 3 instructions directly.
    - sitharus 7mo ago
      The main distinction now is RISC-descended designs use a load-modify-store instruction set with all ALU functions being register-register, and consequently have a lot more (visible) registers than CISC-descended ISAs (mostly just x86 really). 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 https://developer.arm.com/documentation/102160/latest
  - snvzz 7mo ago
    >Code size is a benefit for x86-64 however 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.
    - userbinator 7mo ago
      Decades of demoscene productions beg to differ. That just means compilers are awful, as they usually are.[1] x86 has far more optimisation opportunities than any RISC. [1] https://news.ycombinator.com/item?id=15720923 https://news.ycombinator.com/item?id=15720923
      - snvzz 7mo ago
        In absence of better data, we have to compare compiler output.
        userbinator 7mo ago
        Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...
        sitharus 7mo ago
        If I recall my lectures, which were 20odd years ago now. 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.
        snvzz 7mo ago
        From 2017, it predates RISC-V first ratified spec. 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.
sitharus 7mo ago
A bit more reading shows there's a three instruction general case version for 32-bit additions on the 64-bit RISC-V ISA. I'm not familiar with RISC-V assembly and they didn't provide an example, but I _think_ it's as easy as this since 64-bit add wouldn't match the 32-bit overflowed add. add t0, t1, t2 addw t3, t1, t2 bne t0, t3, overflow

userbinator 7mo ago

Contrast with x86: add eax, ecx jo overflow

rwmj 7mo ago
Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code 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.
- userbinator 7mo ago
  I thought the main distinction of RISC-V (and MIPS before it, along with RISCs in general) is that the instructions are themselves of equivalent complexity (or lack thereof) as x86 uops. E.g x86 can add a register to memory, which splits into 3 load / add / store uops, but a RISC would execute those 3 instructions directly.
  - sitharus 7mo ago
    The main distinction now is RISC-descended designs use a load-modify-store instruction set with all ALU functions being register-register, and consequently have a lot more (visible) registers than CISC-descended ISAs (mostly just x86 really). 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 https://developer.arm.com/documentation/102160/latest
- snvzz 7mo ago
  >Code size is a benefit for x86-64 however 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.
  - userbinator 7mo ago
    Decades of demoscene productions beg to differ. That just means compilers are awful, as they usually are.[1] x86 has far more optimisation opportunities than any RISC. [1] https://news.ycombinator.com/item?id=15720923 https://news.ycombinator.com/item?id=15720923
    - snvzz 7mo ago
      In absence of better data, we have to compare compiler output.
      - userbinator 7mo ago
        Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...
        sitharus 7mo ago
        If I recall my lectures, which were 20odd years ago now. 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.
        snvzz 7mo ago
        From 2017, it predates RISC-V first ratified spec. 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.

sitharus 7mo ago

A bit more reading shows there's a three instruction general case version for 32-bit additions on the 64-bit RISC-V ISA. I'm not familiar with RISC-V assembly and they didn't provide an example, but I _think_ it's as easy as this since 64-bit add wouldn't match the 32-bit overflowed add. add t0, t1, t2 addw t3, t1, t2 bne t0, t3, overflow