On Sat, 2025-01-04 at 16:00 +0100, Arnd Bergmann wrote: > On Thu, Jan 2, 2025, at 19:34, Jiaxun Yang wrote: > > > Why am I upstreaming LoongArch32? > > ================================ > > Although 32-bit systems are experiencing declining adoption in general > > computing, LoongArch32 remains highly relevant within specific niches. > > Beyond embedded applications, several vendors are actively developing > > application-level LoongArch32 processors. Loongson, for example, has > > released two open-source reference hardware implementations: openLA500 > > and openLA1000 [6]. > > > > The architecture also holds considerable educational value, having been > > integrated into China's national computer architecture curricula and > > embedded systems courses. Additionally, the National Student Computer > > System Capability Challenge (NSCSCC) [1] features LoongArch32 CPUs, where > > hundreds of students design Linux-capable hardware implementations and > > compete on performance. This initiative has resulted in several exciting > > high-performance LoongArch32 cores, including LainCore[2], Wired[3], > > NOP-Core[4], NagiCore[5].... > > I'm surprised that so many resources get put into 32-bit hardware > implementations on loongarch, when this has mostly stopped on riscv > and arm, where new hardware is practically all either 64-bit Linux > or 32-bit NOMMU microcontrollers. > > > From an upstream perspective, we will largely reuse the infrastructure > > already established for LoongArch64, ensuring that the maintenance burden > > remains minimal. > > > > Porting Status > > ============== > > The LoongArch32 port has been available downstream for some time, with > > various system components hosted on Loongson's Gitee[6]. However, these > > components utilise an older downstream ABI and fall short of upstream > > quality. > > > > On the upstream front, LLVM-19 now includes experimental support for > > LoongArch32 (ILP32 ABI) under the loongarch32* triple, and efforts are > > underway to enable GNU toolchain support. My upstream-ready kernel port > > and musl libc port can successfully boot into a minimal Buildroot > > environment and execute test cases on QEMU virt machine with clang > > toolchain. > > I assume the MIPS legacy means that a 64-bit kernel is going to be > able to run the same ILP32 binaries as a 32-bit kernel running on > pure 32-bit hardware, similar to powerpc/s390/x86, but unlike > riscv/arm? LoongArch has instructions like addi.d/addi.w, instead of addi/addi.w, thus on 32-bit implementation it's simply addi.d is missing, not the semantic of addi is changed. So I cannot see a real reason we cannot support the same ILP32 userspace binaries compiled for 32-bit hardware on 64-bit hardware. > We need to be careful in defining the ABI to ensure that this covers > all the corner cases, such as defining a signal stack layout with > room to save 64-bit user register contents if there is a chance that > a 32-bit userspace will end up using the wide registers when > running on a 64-bit kernel, but also avoid any dependency on 64-bit > registers in the ABI itself. Yes such issues are nasty, we'd already need something in the calling convention like "on 64-bit hardware, in ILP32 ABI the saved registers may be unchanged or changed to the sign-extension from the lower 32 bits of the original value." -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
