Generic Linux architectural discussions
 help / color / mirror / Atom feed
From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Arnd Bergmann" <arnd@arndb.de>, "Xi Ruoyao" <xry111@xry111.site>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Xuerui Wang" <kernel@xen0n.name>
Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
	Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 0/3] LoongArch: initial 32-bit UAPI
Date: Sun, 05 Jan 2025 12:03:17 +0000	[thread overview]
Message-ID: <69d0df0e-9e44-4227-b2a5-02ce87b1de7e@app.fastmail.com> (raw)
In-Reply-To: <6b2e8382-e4d6-46ce-9d1d-02ddbae76ad3@app.fastmail.com>



在2025年1月5日一月 上午10:27,Jiaxun Yang写道:
> 在2025年1月5日一月 上午4:43,Arnd Bergmann写道:
> [...]
>> If both the ISA and the ABI get it right, it should be possible to
>> build 32-bit userspace that is compatible with both when targeting
>> a 32-bit hardware, but still use 64-bit registers inside a single
>> function when the compiler is building for a 64-bit capable CPU
>> (e.g. "-march=la464 -m32"). There is a small cost in the calling
>> conventions for passing u64 arguments in pairs of registers
>> (unlike n32/x32/aarch64ilp32/rv64ilp32), but a huge benefit in
>> not maintaining two incompatible ABIs.
>

Upon having a closer look, I think there's an issue regarding having uniformed
ABI for LA32 and LA64. I'll call them ILP32GRLEN32 and ILP32GRLEN64 below.

If we allow interlinking, we must treat the upper 32 bits of all GPRs as
caller-saved, since an ILP32GRLEN32 callee would be unaware of them. This
could incur significant performance overhead.

Alternatively, we can disallow interlinking. However, this effectively creates
a new, incompatible ABI. I'm not sure if it still fits our design goal.

Thanks

>>      Arnd
>
> -- 
> - Jiaxun

-- 
- Jiaxun

      reply	other threads:[~2025-01-05 12:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02 18:34 [PATCH 0/3] LoongArch: initial 32-bit UAPI Jiaxun Yang
2025-01-02 18:34 ` [PATCH 1/3] loongarch: Wire up 32 bit syscalls Jiaxun Yang
2025-01-04 15:31   ` Arnd Bergmann
2025-01-02 18:34 ` [PATCH 2/3] loongarch: Introduce sys_loongarch_flush_icache syscall Jiaxun Yang
2025-01-04  9:04   ` Jinyang Shen
2025-01-04 11:18     ` Jiaxun Yang
2025-01-04 15:07     ` Arnd Bergmann
2025-01-04 15:42       ` Jiaxun Yang
2025-01-04  9:31   ` Xi Ruoyao
2025-01-04 11:33     ` Jiaxun Yang
2025-01-02 18:34 ` [PATCH 3/3] loongarch: vdso: Introduce __vdso_flush_icache function Jiaxun Yang
2025-01-04  8:27 ` [PATCH 0/3] LoongArch: initial 32-bit UAPI Jinyang Shen
2025-01-04 15:00 ` Arnd Bergmann
2025-01-04 15:13   ` Xi Ruoyao
2025-01-04 16:03     ` Jiaxun Yang
2025-01-05  4:43       ` Arnd Bergmann
2025-01-05 10:27         ` Jiaxun Yang
2025-01-05 12:03           ` Jiaxun Yang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69d0df0e-9e44-4227-b2a5-02ce87b1de7e@app.fastmail.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=arnd@arndb.de \
    --cc=chenhuacai@kernel.org \
    --cc=kernel@xen0n.name \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox