[irusensei]

I feel this is becoming a bit of a tech urban legend such as ZFS requires ECC.

As far as I understand the RVA23 requirement is an ubuntu thing only and only for current non LTS and future releases. Current LTS doesn't have such requirements and neither other distributions such as Fedora and Debian that support riscv64.

So no, you are not stuck running custom vendor distros because of this but more because the other weird device drivers and boot systems that have no mainline support.

[alexrp]

I'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available.

It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.

[rwmj]

As someone from the Fedora/RISC-V project, it'll depend on what our users want. We cannot support both RV64GC and RVA23 (because we don't have the build or software infra to do it) so we have to be careful when we move. Doing something like building with RV64GC generally but having targeted optimizations - perhaps two kernel variants and some libraries - might be possible, but also isn't easy.

Things are different for CentOS / RHEL where we'll be able to move to RVA23 (and beyond) much more aggressively.

[fweimer]

I'm not completely sure, but I suspect Fedora will stick to the current baseline for quite some time.

But the baseline is quite minimal. It's biased towards efficient emulation of the instructions in portable C code. I'm not sure why anyone would target an enterprise distribution to that.

On the other hand, even RVA23 is quite poor at signed overflow checking. Like MIPS before it, RISC-V is a bet that we're going to write software in C-like languages for a long time.

[camel-cdr]

> On the other hand, even RVA23 is quite poor at signed overflow checking

When I tried to measure the impact of -ftrapv in RVA23 and armv9, it was roughly the same: https://news.ycombinator.com/item?id=46228597#46250569

reminder:

    unsigned 64-bit:
    add: RV: add+bltu       Arm: adds+bcc
    sub: RV: sub+bltu       Arm: subs+bcs
    mul: RV: mulhu+mul+beqz Arm: umulh+mul+cbz
    
    unsigned 32-bit:
    add: RV: addw+bgeu     Arm: adds+bcc
    sub: RV: subw+bgeu     Arm: subs+bcs
    mul: RV: mul+slli+beqz Arm: umul+cmp lsr 32

    signed 64-bit:
    add: RV: add+slt+slti+beq  Arm: adds+bcc
    sub: RV: sub+slt+slti+beq  Arm: subs+bcs
    mul: RV: mulh+mul+srai+beq Arm: smulh+mul+cmp asr 63
    
    signed 32-bit:
    add: RV: addw+add+beq   Arm: adds+bvc
    sub: RV: subw+sub+beq   Arm: subs+bvs
    mul: RV: mul+sext.w+bew Arm: smul+asr+cmp asr 31

[IshKebab]

> On the other hand, even RVA23 is quite poor at signed overflow checking.

On the other hand it avoids integer flags which is nice. I doubt it makes a measurable performance impact either way on modern OoO CPUs. There's going to be no data dependence on the extra instructions needed to calculate overflow except for the branch, which will be predicted not-taken, so the other instructions after it will basically always run speculatively in parallel with the overflow-checking instructions.