On 26 Apr 2023, at 17:22, Bo YU <tsu.y...@gmail.com> wrote: > > Hi, > On Tue, Apr 25, 2023 at 02:08:33PM -0400, Darius Rad wrote: >> On Tue, Apr 25, 2023 at 10:52:52PM +0800, Bo YU wrote: >>> On Tue, Apr 25, 2023 at 04:22:49AM +0200, Guillem Jover wrote: >>> >>> > >>> > > I thought the riscv32 has met the request[2] also. >>> > >>> > I assume the ABI is set in stone and well defined. >>> > >> >> There are three ABIs for 32-bit RISC-V. They are well defined, but it is >> not clear which ABI is being proposed for Debian here. >> >>> > > Please let me know if there is any issue. >>> > >>> > I think at the time when we added riscv64 we didn't also add riscv32 >>> > because it was not clear whether there was then interest or demand, >>> > and I don't recall whether there were concerns about what ISA baseline >>> > to choose? (But I guess this would use the default baseline specified >>> > currently by the compiler.) >>> >>> There is no doubt that the porting of riscv64 is our first priority and >>> it's already in a good shape -- except for the official port.:( >>> >>> For riscv32 case, I think it'd be pretty helpful to let users to setup >>> rv32 Debian rootfs or to let rv32 Debain run on RISC-V 32 bit hardware that >>> will be emerged in the near future. >> >> Do you have any references for this hardware? > > From my vague memory, there will be k230 fully support rv32 in userspace > from canaan. Sorry, I was trying to find news or useful url but fail > here.
From what I can see it’s using a C908 which is RV64. Maybe it can also do RV32 if you switch mode, but why would you, just as we don’t recommend people run i386 on amd64. RV32-only Unix-capable hardware would be more interesting, but seems like a foolish thing to build in this decade. >>> Here I simply assume that rv32 compiler with `--with-arch=rv32gc >>> --with-abi=ilp32d`[0] is enough? >>> >> >> That is one choice, but not the only one. >> >> The argument in favor of a 32-bit port of RISC-V is typically motivated by >> the assumption that such processors will be smaller, in terms of the >> hardware (i.e., ASIC gates or FPGA LUTs). However, as compared to rv64gc, >> eliminating floating point typically provides a much more significant >> decrease in size. Thus, often when one is talking about smaller, 32-bit >> RISC-V processors, they *also* eliminate floating point. In other words, >> the processors are rv32imac, not rv32gc. >> >> In fact, I wouldn't be surprised if rv64imac processors were more common >> than rv32gc, given the minimal hardware resources for 64-bit versus 32-bit, >> all else being equal. > > Thanks for explaining this. Here are some of my thoughts about it. > > I think, as a distribution, we should provide a basic baseline of > instruction set supported to cover most hardware vendors. We should not > assume that hardware vendors will product their CPUs on a certain instruction > set. We should support hardware that does exist, not hardware that might exist. So long as there is no RV32-only Unix-capable hardware out there, what is the point in Debian producing a distribution? > In addition, refer to other 32-bit architectures, like armhf[1] and mips[2], > They are also supporting floating point instructions(IIUC). Because they date back to when 32-bit computing was common practice, and wanted floating-point. These days, 64-bit is the standard, and there is little motivation for building a 32-bit core with floating-point given the tiny additional area needed to make it 64-bit (especially since you already need 64-bit data paths for the D extension). > Also, keep > the same baseline with rv64, maybe it will reduce confusion for users. > I am not sure how much would we benefit from dropping support for 'F' or > 'D', but maybe we can't lost something if we support full set(rv32gc) > from port's view. If you’re going to provide a distribution for RV32, dropping F and D seems like the right thing to do, since that’s the only sensible thing to build hardware for. But why commit to one now when nothing exists yet to motivate any of them. Jess > [0]: https://www.canaan.io/ > [1]: > https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L485 > [2]: > https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L646 > >> >> // darius >> > > -- > Regards, > -- > Bo YU
