Because implementing an ABI, or dealing with an incompatibnle change, is hard
work. Also, ABI stability means that old binaries work. So ABI stability
isn't so much a requirement for the compiler as it is a requirement for any
sane operating system. An OS that changes ABI without an extremely good reason
is an OS that doesn't care about compatibility, which means it doesn't care
about its customers.
The MIPS examples I pointed to are a good illustration of this. The original
("O32") ABI is for MIPS with 32 bit registers and 32 bit addressing. N32 and
N64 were introduced by SGI to support 64 bit registers, and (for N64) 64 bit
pointers. That's a very compelling benefit. 64 bbit addressing is obvious,
and the performance benefit from using 64 bit registers on machines that have
them is very large. So there, the quite large cost of doing this was totally
justified.
paul
> On Jul 9, 2023, at 4:55 PM, André Albergaria Coelho via Gcc <gcc@gcc.gnu.org>
> wrote:
>
> If we can select the ABi for our program (using gcc), why is there a need for
> ABI stability?!
>
> why not put it on a define
>
>
> #define abi v3
>
> int main() {
>
> }
>
>
> Each user would just have to compile the code, to follow the abi...no need to
> worry changing it
>
>
> thanks
>
>
> andre
>
