On Fri, May 19, 2023 at 8:14 AM Paul Walmsley <paul.walmsley@xxxxxxxxxx> wrote: > > On Thu, 18 May 2023, Palmer Dabbelt wrote: > > > On Thu, 18 May 2023 06:09:51 PDT (-0700), guoren@xxxxxxxxxx wrote: > > > > > This patch series adds s64ilp32 support to riscv. The term s64ilp32 > > > means smode-xlen=64 and -mabi=ilp32 (ints, longs, and pointers are all > > > 32-bit), i.e., running 32-bit Linux kernel on pure 64-bit supervisor > > > mode. There have been many 64ilp32 abis existing, such as mips-n32 [1], > > > arm-aarch64ilp32 [2], and x86-x32 [3], but they are all about userspace. > > > Thus, this should be the first time running a 32-bit Linux kernel with > > > the 64ilp32 ABI at supervisor mode (If not, correct me). > > > > Does anyone actually want this? At a bare minimum we'd need to add it to the > > psABI, which would presumably also be required on the compiler side of things. > > > > It's not even clear anyone wants rv64/ilp32 in userspace, the kernel seems > > like it'd be even less widely used. > > We've certainly talked to folks who are interested in RV64 ILP32 userspace > with an LP64 kernel. The motivation is the usual one: to reduce data size > and therefore (ideally) BOM cost. I think this work, if it goes forward, > would need to go hand in hand with the RVIA psABI group. > > The RV64 ILP32 kernel and ILP32 userspace approach implemented by this > patch is intriguing, but I guess for me, the question is whether it's > worth the extra hassle vs. a pure RV32 kernel & userspace. Running pure RV32 kernel on 64-bit hardware is not an intelligent choice (such as cortex-a35/a53/a55), because they wasted 64-bit hw capabilities, and the hardware designer would waste additional resources & time on 32-bit machine & supervisor modes (In arm it is called EL3/EL2/EL1 modes). Think about too many PMP CSRs, PMU CSRs, and mode switch ... it's definitely wrong to follow the cortex-a35/a53/a55 way to deal with riscv32 on a 64-bit hardware. The chapter "Why s64ilp32 has better performance?" give out the improvement v.s. pure 32-bit, I repeat it here: - memcpy/memset/strcmp (s64ilp32 has half of the number of instructions and double the bandwidth per load/store instruction than s32ilp32.) - ebpf JIT is a 64-bit virtual ISA, which couldn't be sufficient mapping by s32ilp32, but s64ilp32 could (just like s64lp64). - Atomic64 (s64ilp32 has the exact native instructions mapping as s64lp64, but s32ilp32 only uses generic_atomic64, a tradeoff & limited software solution.) - 64-bit native arithmetic instructions for "long long" type - riscv s64ilp32 could support cmxchg_double for slub (The 2nd 32-bit Linux supports the feature, the 1st is i386.) > > > - Paul -- Best Regards Guo Ren
