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_at_[hidden]> 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
>
>
>
>