On Tue, Apr 23, 2024 at 09:43:34AM +0300, David Abdurachmanov wrote:
On Mon, Apr 22, 2024 at 1:12 PM Florian Weimer
<fweimer(a)redhat.com> wrote:
> > We most likely will not have ABIs installed in parallel, but we might
> > change ABI. Currently Linux distributions target "RV64GC", but we
> > don't really want that for the future RISC-V. I keep telling folks
> > that "RV64GC" is already "a legacy" (10+ years old), but
that's the
> > major target for the next few years. We are scheduled to see some
> > RVA22 SBCs this year.
> >
> > RV64GC -> RVA20 -> RVA22 -> RVA23 -> RVA24.
> >
> > That's how things evolved. RVA23 most likely will be ratified soonish.
> > RVA24 is most likely the next major RISC-V Profile from RVI point of
> > view (TBD). Server specifications are based on RVA23 (and will be
> > updated to RVA24 [most likely]). This defines baseline ISA, optional
> > extensions, etc.
>
> Is there really an ABI change, though? That would only happen if the
> set of callee-saved registers grows, to include vector registers.
> Adding new registers has compatibility problems on its own.
There are two conventions for vectors in RISCV psABI: "standard" and
"calling" (not the best name).
standard does not have preserved registers across calls.
calling one does (similar to what you would expect from AVX).
The default today is standard, which means that -march=rv64gv
-mabi=lp64d enables vectors and we can mix them with existing
binaries. This is a very limited use of vectors.
GCC 14 is the 1st release that has vector support for RISCV. There
might be suggestions to add lp64dv as ABI in the future (maybe GCC 15?
Unknown) that would default to the vector calling convention. There
might be more extensions that could require ABI change IIUC, but I
don't recall the details.
RVA23 requires vectors, and vector crypto. Android will also require
vectors, it's not an option.
I hope that once RVA23 and especially RVA24 lands, RVI will announce
the next major RISCV profile (RVA24, might have a fancier marketing
name). We will see what the market does, but we have already seen some
cores being marketed as RVA24 (yet I don't really trust that). Once we
start looking at the next baseline ISA we might as well pick the best
ABI for it. We could call this "Fedora/RISCV.Next". RV64GC will
probably be 10-15 years old by that time, and it lacks any modern ISA
especially if you want high performance. I consider RVA24 a point
where we close major gaps between RISCV and other popular arches.
Wouldn't changing -mabi effectively make the result a new Fedora
architecture? IIUC, binaries built with -mabi=lp64d wouldn't be able
to load libraries built with -mabi=lp64dv and vice versa.
If that's correct, then we can't simply have a single "riscv64"
architecture: instead, we need to call what we have today
riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever
comes next.
It would be somewhat similar to existing architectures that can be
used in both Little-Endian (ppc64le) and Big-Endian (ppc64) modes.
This is quite different from just bumping the ISA baseline, where
existing binaries and libraries are still usable in the new
environment.
--
Andrea Bolognani / Red Hat / Virtualization