Investigate the switch to RVA23 baseline

kashyapc commented

2026-09-15 21:56:45 +00:00

Owner

Fedora’s current baseline instruction set is RV64GC. This ticket aims capture our thinking on RVA23 and when to switch to it, to keep it all in one place.

We need to decide on a reference hardware platform. There is some RVA23 hardware in the market, most prominently, Spacemit K3. Should K3 be the reference hardware? Something else?

Fedora’s current baseline instruction set is `RV64GC`. This ticket aims capture our thinking on RVA23 and when to switch to it, to keep it all in one place. We need to decide on a reference hardware platform. There is some RVA23 hardware in the market, most prominently, Spacemit K3. Should K3 be the reference hardware? Something else?

davidlt commented

2026-09-16 10:17:18 +00:00

Owner

My current view is that we want at least 1 or 2 (it would be better) RVA23 ISA capable platforms with upstream stack support. If the target is SBC this would incl. OpenSBI, U-Boot/EDK2 (at least one of them) and Linux kernel. We should be able to rebuild all those deliverables. If the target ships with UEFI+ACPI+SMBIOS out-of-the-box experience like on PC we more likely not to have such access, which is fine. In that case firmware is part of hardware. This is more likely for Server spec compliant hardware, which we don't have today. Tenstorrent hardware might be that in the future (i.e. Atlantis), but it might not be on day 1.

RFC for a new ABI that would enable vectors by default didn't land. It's unlikely that distribution would adopt it now.

This means we would be switching to a new baseline ISA, but keeping existing ABI which does not enable vectors by default. That means we should be able to mix our existing and RVA23 binaries. This means it staged transition, and we don't need a new complicated/expensive bootstrap process. This mainly means we would configure GCC and LLVM to default to RVA23.

My current view is that we want at least 1 or 2 (it would be better) RVA23 ISA capable platforms with upstream stack support. If the target is SBC this would incl. OpenSBI, U-Boot/EDK2 (at least one of them) and Linux kernel. We should be able to rebuild all those deliverables. If the target ships with UEFI+ACPI+SMBIOS out-of-the-box experience like on PC we more likely not to have such access, which is fine. In that case firmware is part of hardware. This is more likely for Server spec compliant hardware, which we don't have today. Tenstorrent hardware might be that in the future (i.e. Atlantis), but it might not be on day 1. RFC for a new ABI that would enable vectors by default didn't land. It's unlikely that distribution would adopt it now. This means we would be switching to a new baseline ISA, but keeping existing ABI which does not enable vectors by default. That means we should be able to mix our existing and RVA23 binaries. This means it staged transition, and we don't need a new complicated/expensive bootstrap process. This mainly means we would configure GCC and LLVM to default to RVA23.

fweimer commented

2026-09-16 10:24:01 +00:00

@davidlt wrote in #31 (comment):

RFC for a new ABI that would enable vectors by default didn't land. It's unlikely that distribution would adopt it now.

Could you elaborate on what that means? Is it about using vector registers for argument passing even if no (obvious) vector types are involved?

@davidlt wrote in https://forge.fedoraproject.org/riscv/planning/issues/31#issuecomment-1357492: > RFC for a new ABI that would enable vectors by default didn't land. It's unlikely that distribution would adopt it now. Could you elaborate on what that means? Is it about using vector registers for argument passing even if no (obvious) vector types are involved?

davidlt commented

2026-09-16 11:27:41 +00:00

Owner

There are two vector register conventions. The default one does not preserve vector registers across calls. Simply put we are using LP64D which doesn't incl. vector registers in calling conventions.

There is a second calling convention documented. You can use via it attribute. See: https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#riscv_vector_cc

There was an idea to add new ABI LP64DV that would default to a calling convention variant. See: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662292.html

There are two vector register conventions. The default one does not preserve vector registers across calls. Simply put we are using LP64D which doesn't incl. vector registers in calling conventions. There is a second calling convention documented. You can use via it attribute. See: https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#riscv_vector_cc There was an idea to add new ABI LP64DV that would default to a calling convention variant. See: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662292.html

fweimer commented

2026-09-21 17:48:14 +00:00

@davidlt Thanks. Yes, adding additional callee-saved registers can be challenging because jmp_buf and ucontext_t typically need to change sizes. This is beyond what can be done with symbol versioning. There's also no glibc support for multi-ABI floating point types besides long double, so it would have to be a completely separate port, with its own dynamic linker etc.

@davidlt Thanks. Yes, adding additional callee-saved registers can be challenging because `jmp_buf` and `ucontext_t` typically need to change sizes. This is beyond what can be done with symbol versioning. There's also no glibc support for multi-ABI floating point types besides `long double`, so it would have to be a completely separate port, with its own dynamic linker etc.

Rows
Columns

Investigate the switch to RVA23 baseline #31