On 27 Dec 2021, at 01:16, Guo Ren [off-list ref] wrote:

On Mon, Dec 27, 2021 at 4:31 AM Arnd Bergmann [off-list ref] wrote:

quoted

On Sun, Dec 26, 2021 at 7:38 AM Guo Ren [off-list ref] wrote:

quoted

On Sun, Dec 26, 2021 at 4:36 PM Jisheng Zhang [off-list ref] wrote:

quoted

On Wed, 22 Dec 2021 20:59:30 +0800 Guo Ren [off-list ref] wrote:

quoted

On Wed, Dec 22, 2021 at 2:10 AM Arnd Bergmann [off-list ref] wrote:

What about adding RV64 ILP32 support instead? This don't need HW side
modifications so can benefit all RV64.

ILP32 is another topic in C Language Data Type Models and it couldn't
replace the standard rv32 ecosystem.
COMPAT is a common framework in Linux (7 arches have been supported),
so let rv64 support COMPAT mode is considerable.

Customers would choose ILP32 / RV32-compat by themself and that
depends on which one has a better ecosystem.

From a kernel perspective, supporting both is not much more work than
supporting either of them. We had the same debate for Arm64, and ended
up never merging the ILP32 patches despite them being well written
and maintainable, to limit the number of supported user space ABIs
as well as the possible attack vectors when there is an exploitable
bug that is specific to an ABI.

arm64 does support big-endian mode, which is a similar niche, but it
can't easily be removed after it's already supported. Supporting normal
compat mode is the easiest here because it doesn't add another user
space ABI, but I'd strongly recommend not to add any other ones.

@Palmer Dabbelt How do you think about supporting ILP32 & COMPAT both
in rv64? And let users vote by foot which is better.

As psABI TG co-chair I really do not want an ILP32 RV64 to exist if it
can at all be avoided. Every single attempt at an ILP32 ABI for a
64-bit architecture has failed to take off in the past, so I struggle
to see why RV64 will be any different. So, in my opinion, there is a
relatively high barrier to entry for it to be an official frozen ABI,
and without it being that I doubt upstreams will want to go near it, be
it Linux, GCC, binutils or GCC, but they can speak for themselves if
they feel otherwise.

Also, with every year that goes by, ILP32 becomes more and more limited
in what you can use it for, due to increased memory footprints...

Jess


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv