>
> Do you know many 32-bit applications written in the late 90s and early 90s
> that did that? Even if people had the foresight of predicting 64-bit
> (because
> the transition to 32-bit on x86 was less than 10 years old at that time),
> would they take this recommendation? Computers at the time had a handful
> of MB
> of total RAM, they'd balk at wasting bytes in structures like that.
>


> For that matter, why are we not writing 128-bit-pointer-safe code today?
> Let's
> take the newest architecture: RISC-V 64-bit. Why isn't its ABI using
> 128-bit
> pointers? It's not like we are constrained for memory now.


There was never a need to apply forsight for those apps, nor is there a
need to link the same library directly. For example could have libstdc64.so
> libstdc.so > app.elf
The point was that it should've been possible to maintain just one main ABI
and just make old ABIs wrappers to the current. Likewise to your 128bit
mention it would be libstdc128 > libstdc64.so > app.elf for apps that
developed for libstdc64.so. Your barking up the wrong tree when you think
apps have to design for the future to link to newer architecture ABIs when
the architectures in question inherit from the architecture they were
designed for. That said why is it named x86_64 if there are instructions
treated differently? It should be just x64 at that point because it's not
doing what x86 expects on some/all of the instructions it inherited.

On Sun, 14 Jul 2024 at 15:47, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday 14 July 2024 07:30:45 GMT-7 Thiago Macieira via Std-Proposals
> wrote:
> > > Shouldn't x86_64
> > > functions just map to 32bit address when linked to 32bit applications?
> >
> > If that had been the design, maybe. It wasn't. There's no mechanism on
> ELF
> > platforms to even load a 64-bit piece of code on a 32-bit application or
> > vice- versa: the loader refuses to open and interpret an ELF binary that
> is
> > of the wrong class or data order.
>
> The ELF machine type isn't even the same, actually.
>
> When 64-bit x86 and ARM were designed, both actually reserved the 32-bit
> mode
> for their new machine types for a ILP32 content running in the same
> processor
> mode (what in x86-land we called "x32"). The idea was to have the cake and
> eat
> it too: have access to the wider register set (16 registers in x86-64, 32
> registers in AArch64), better support for 64-bit quantities, and in the
> case
> of x86, better support for position-relative data access, while still
> keeping
> 32-bit-wide pointers for data compactness. This would also allow easier
> porting of applications that were not 64-bit ready.
>
> x32 mode was added to the Linux kernel but is on the verge of being
> removed
> due to lack of use and support. ILP32 AArch64 was never even added. ILP32
> IA-64 was designed in 2001 when this type of conversion was far more
> relevant
> but was not added to Linux either.
>
> PS: PPC64 is a different machine from PPC 32-bit type in ELF too.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>