Message-ID: <4504b10e4a0bfd09d9a3c719d234295bb638aa3f.camel@xry111.site>
Date: Sat, 04 Jan 2025 23:13:14 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Arnd Bergmann <arnd@...db.de>, Jiaxun Yang <jiaxun.yang@...goat.com>, 
 Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org, Linux-Arch
	 <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 0/3] LoongArch: initial 32-bit UAPI

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@...111.site>
School of Aerospace Science and Technology, Xidian University

Powered by blists - more mailing lists