On Wed, Apr 24, 2024 at 06:07:38AM -0400, Andrea Bolognani wrote: > 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. There's no point having different package names like this because how would it help? You're not going to parallel install them. If we ever wanted to do this we're going to have to coordinate a rebuild across the whole distribution. For this reason I don't see how either having separate /usr/lib64/<subarch> or different RPM package names helps at all. Rich. > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- _______________________________________________ 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
