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.
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 ofinstruction set supported to cover most hardware vendors. We should not assume that hardware vendors will product their CPUs on a certain instruction
set.In addition, refer to other 32-bit architectures, like armhf[1] and mips[2], They are also supporting floating point instructions(IIUC). 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. [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
Attachment:
signature.asc
Description: PGP signature