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@xxxxxxxxxx> 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 -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
