3 ms·

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 ef

by fweimer 9mo ago

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.

IshKebab 9mo ago
> 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.
- fweimer 9mo ago
  It's nice for a C simulator to avoid condition codes. It's not so nice if you want consistent overflow checks (e.g., for automatically overflowing from fixnums to bignums). Even with XNOR (which isn't even part of RVA23, if I recall correctly), the sequence for doing an overflow check is quite messy. On AArch64 and x86-64, it's just the operation followed by a conditional jump: https://godbolt.org/z/968Eb1dh1 https://godbolt.org/z/968Eb1dh1
  - adgjlsfhk1 9mo ago
    Non-flag based overflow checks are still pretty cheap. The overflow check is only 1 extra instruction for unsigned (both add and multiply), and 3/4 extra for signed overflow (see https://godbolt.org/z/nq1nb5Whr https://godbolt.org/z/nq1nb5Whr for details). It's also worth noting that in many cases, the overflow checks will be removable or simplify-able by the compiler entirely (e.g. if you're adding 1 or know the sign of one of the operands etc). As such, the extra couple instructions are likely worthwhile if it makes designing a wider core easier. Signed overflow instructions would be reasonable to add, but it's not like modern high performance cores are bottlenecked by scalar instructions that don't touch memory anyway.
camel-cdr 9mo ago
> 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 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

by fweimer 9mo ago

IshKebab 9mo ago

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

fweimer 9mo ago
It's nice for a C simulator to avoid condition codes. It's not so nice if you want consistent overflow checks (e.g., for automatically overflowing from fixnums to bignums). Even with XNOR (which isn't even part of RVA23, if I recall correctly), the sequence for doing an overflow check is quite messy. On AArch64 and x86-64, it's just the operation followed by a conditional jump: https://godbolt.org/z/968Eb1dh1 https://godbolt.org/z/968Eb1dh1
- adgjlsfhk1 9mo ago
  Non-flag based overflow checks are still pretty cheap. The overflow check is only 1 extra instruction for unsigned (both add and multiply), and 3/4 extra for signed overflow (see https://godbolt.org/z/nq1nb5Whr https://godbolt.org/z/nq1nb5Whr for details). It's also worth noting that in many cases, the overflow checks will be removable or simplify-able by the compiler entirely (e.g. if you're adding 1 or know the sign of one of the operands etc). As such, the extra couple instructions are likely worthwhile if it makes designing a wider core easier. Signed overflow instructions would be reasonable to add, but it's not like modern high performance cores are bottlenecked by scalar instructions that don't touch memory anyway.

camel-cdr 9mo ago

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