Skip to content

[AAPCS64] Remove ILP32 Support - #413

Open
smithp35 wants to merge 1 commit into
ARM-software:mainfrom
smithp35:ilp32aapcs64
Open

[AAPCS64] Remove ILP32 Support#413
smithp35 wants to merge 1 commit into
ARM-software:mainfrom
smithp35:ilp32aapcs64

Conversation

@smithp35

Copy link
Copy Markdown
Contributor

ILP32 support for ELF platforms in the documents has been in perpetual Beta, with new additions to the ABI not considering ILP32. Now that the one complete implementation in GCC has been deprecated (https://gcc.gnu.org/gcc-15/changes.html) we will be removing ILP32 from the ABI documentation.

Part of #369

ILP32 support for ELF platforms in the documents has been in perpetual
Beta, with new additions to the ABI not considering ILP32. Now that
the one complete implementation in GCC has been deprecated
(https://gcc.gnu.org/gcc-15/changes.html) we will be removing ILP32
from the ABI documentation.

Part of ARM-software#369
Comment thread aapcs64/aapcs64.rst
================================

The base standard defines a machine-level calling standard for the A64 instruction set. It assumes the availability of the vector registers for passing floating-point and SIMD arguments. Application code is expected to conform to one of three data models defined in this standard; ILP32, LP64 or LLP64.
The base standard defines a machine-level calling standard for the A64 instruction set. It assumes the availability of the vector registers for passing floating-point and SIMD arguments. Application code is expected to conform to one of three data models defined in this standard; LP64 or LLP64.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The base standard defines a machine-level calling standard for the A64 instruction set. It assumes the availability of the vector registers for passing floating-point and SIMD arguments. Application code is expected to conform to one of three data models defined in this standard; LP64 or LLP64.
The base standard defines a machine-level calling standard for the A64 instruction set. It assumes the availability of the vector registers for passing floating-point and SIMD arguments. Application code is expected to conform to one of two data models defined in this standard; LP64 or LLP64.

Comment thread aapcs64/aapcs64.rst
The number of 64-bit “vector granules” in an SVE vector; in other words,
the number of bits in an SVE vector register divided by 64.

ILP32

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not referencing this at all anymore except for the changelog and the note that we removed it which itself includes a quick summary, so remove here as well?

Comment thread aapcs64/aapcs64.rst

This specification does not standardize the representation of publicly visible C++-language entities that are not also C language entities (these are described in `CPPABI64`_) and it places no requirements on the representation of language entities that are not visible across public interfaces.

**(Beta)** suppport for ILP32 SysV-like variant where int, long int and pointer are 32-bit, has been removed. Refer to a previous binary release of the ABI for **(Beta)** ILP32 documentation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think describing the beta feature with beta markers is confusing here. At first I read it as removal of the feature being beta.

Suggested change
**(Beta)** suppport for ILP32 SysV-like variant where int, long int and pointer are 32-bit, has been removed. Refer to a previous binary release of the ABI for **(Beta)** ILP32 documentation.
Beta suppport has been removed for the ILP32 SysV-like variant where int, long int and pointer are 32-bit. Refer to a previous binary release of the ABI for Beta ILP32 documentation.

TBH I would remove this line altogether. We already mention it in the change log and I feel we don't need to keep a changelog in the text of the things we removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants