I agree it's pointless to argue it now, though I do question why there's a need to switch modes when x86_64 is a superset of x86. Shouldn't x86_64 functions just map to 32bit address when linked to 32bit applications? As long as the application knows to expect bigger addresses from pointer functions defined by x86_64 code then there'd be no issue. For example in the headers it could be as simple as

#ifdef __x86_64__

void* foo(...);

void* bar(...) { return foo(0,...); }

#else

uint64_t foo(...);

void* bar(...) { return (void*)(uintptr_t)foo(MAP_32BIT,...); }

#endif

The compiler will quickly catch any invalid usages and the define or inline wrapper could be right next to the function so that when it does the dev can see why their usage was invalid.

On Sun, 14 Jul 2024 at 14:36, Thiago Macieira <thiago@macieira.org> wrote:

On Sunday 14 July 2024 06:29:10 GMT-7 zxuiji wrote:
> Why are those registers used? Why not RAX and RBX? 64bit functions should be
> able to call 32bit functions since they should be used the same registers,
> just under different sizes. Without that I see no reason for the MAP_32BIT
> flag linux has in the userspace function mmap().

That flag is intended for emulators and other very low-level type code that is
probably written in assembly or has such a translation layer (think libffi).
It's not intended for regular applications, except for the broken ones that
need to store a pointer but only have 32 bits with which to do so. Note you
need also to do a transition between CPU modes, which is not something the
compiler will do for you, and you must call the 32-bit code *from* a below-4GB
address, otherwise the 32-bit code can't return. The CPU can do it -- all you
need is an 80-bit indirect far call.

Why is RAX not used? Because it is too useful to pass an argument in, as there
are several instructions that implicitly use it and that would require the
leaf function or thunk code to save the parameter that would be there
somewhere else.

In any case, it's pointless to argue this now. The decision was made 20 years
ago. In-process compatibility of 32- and 64-bit code was not a requirement.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Platform & System Engineering