[PATCH v2] Add _BitInt(N) from ISO/IEC WG14 N2763

[H.J. Lu]

---
x86-64-ABI/low-level-sys-info.tex | 34 +++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)

diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
index e4fd6d9..04839de 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++ b/x86-64-ABI/low-level-sys-info.tex
@@ -274,6 +274,34 @@ but otherwise behave identically. The only exceptions are that
\code{__m128}, \code{__m256} and \code{__m512} must always be aligned
properly.

+\subsubsection{Fundamental Types of N-bit Integers}
+
+\texttt{_BitInt(N)} from ISO/IEC WG14 N2763, where \code{N} is an
+integral constant expression representing the exact number of bits to
+be used to represent the type, is a family of integer types.
+
+\begin{itemize}
+ \item \texttt{_BitInt(N)} types are signed by default, and
+ \texttt{unsigned _BitInt(N)} types are unsigned.
+ \item \texttt{_BitInt(N)} types are stored in little-endian order in
+ memory. Bits in each byte are allocated from right to left.
+ \item For N <= 64, they have the same size and alignment as
+ the smallest of (signed and unsigned) \code{char}, \code{short},
+ \code{int}, \code{long} and \code{long long} types that can contain
+ them.
+ \item For N > 64, they are treated as struct of 64-bit integer
+ chunks. The number of chunks is the smallest number that can contain
+ the type. \texttt{_BitInt(N)} types are byte-aligned to the next
+ greatest power-of-2 up to 64 bits. The size of these types is the
+ smallest multiple of the 64-bit chunks greater than or equal to N.
+ \item The value of the unused bits beyond the width of the
+ \texttt{_BitInt(N)} value but within the size of the
+ \texttt{_BitInt(N)} are unspecified when stored in memory or register.
+\end{itemize}
+
+This permits the use of these types in allocated arrays using the common
+sizeof(Array)/sizeof(ElementType) pattern.
+
\subsubsection{Aggregates and Unions}

Structures and unions assume the alignment of their most strictly
@@ -563,6 +591,12 @@ typedef struct {
with the exception that arguments of type \code{__int128} that are
stored in memory must be aligned on a 16-byte boundary.

+\item Arguments of type \code{_BitInt(N)} with N <= 64 are in the
+INTEGER class.
+
+\item Arguments of type \code{_BitInt(N)} with N > 64 are classified
+as if they were implemented as struct of 64-bit integer fields.
+
\item Arguments of \code{complex T} where \code{T} is one of the types
\code{_Float16, float, double or __float128} are treated as if they are
implemented as:
--
2.31.1

[Florian Weimer]

* H. J. Lu:

> ---
> x86-64-ABI/low-level-sys-info.tex | 34 +++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
> index e4fd6d9..04839de 100644
> --- a/x86-64-ABI/low-level-sys-info.tex
> +++ b/x86-64-ABI/low-level-sys-info.tex
> @@ -274,6 +274,34 @@ but otherwise behave identically. The only exceptions are that
> \code{__m128}, \code{__m256} and \code{__m512} must always be aligned
> properly.
>
> +\subsubsection{Fundamental Types of N-bit Integers}
> +
> +\texttt{_BitInt(N)} from ISO/IEC WG14 N2763, where \code{N} is an
> +integral constant expression representing the exact number of bits to
> +be used to represent the type, is a family of integer types.
> +
> +\begin{itemize}
> + \item \texttt{_BitInt(N)} types are signed by default, and
> + \texttt{unsigned _BitInt(N)} types are unsigned.
> + \item \texttt{_BitInt(N)} types are stored in little-endian order in
> + memory. Bits in each byte are allocated from right to left.

Right to left in register contents, left to right in memory contents, I
think.

> + \item For N <= 64, they have the same size and alignment as
> + the smallest of (signed and unsigned) \code{char}, \code{short},
> + \code{int}, \code{long} and \code{long long} types that can contain
> + them.
> + \item For N > 64, they are treated as struct of 64-bit integer
> + chunks. The number of chunks is the smallest number that can contain
> + the type.

Suggest an \item here because the following part applies to more than
just $N > 64$.

> \texttt{_BitInt(N)} types are byte-aligned to the next
> + greatest power-of-2 up to 64 bits. The size of these types is the
> + smallest multiple of the 64-bit chunks greater than or equal to N.
> + \item The value of the unused bits beyond the width of the
> + \texttt{_BitInt(N)} value but within the size of the
> + \texttt{_BitInt(N)} are unspecified when stored in memory or register.
> +\end{itemize}
> +
> +This permits the use of these types in allocated arrays using the common
> +sizeof(Array)/sizeof(ElementType) pattern.
> +

So inside a struct, _BitInt(65) has 8-byte alignment, but a global
variable of _BitInt(65) type has 16-byte alignment? If that's the
intent, the description seems sufficiently unambiguous to me.

Thanks,
Florian

[Joseph Myers]

On Sun, 15 Aug 2021, Florian Weimer wrote:

> > +\begin{itemize}
> > + \item \texttt{_BitInt(N)} types are signed by default, and
> > + \texttt{unsigned _BitInt(N)} types are unsigned.
> > + \item \texttt{_BitInt(N)} types are stored in little-endian order in
> > + memory. Bits in each byte are allocated from right to left.
>
> Right to left in register contents, left to right in memory contents, I
> think.

I don't think "right" and "left" are very helpful terms to use here.

>
> > + \item For N <= 64, they have the same size and alignment as
> > + the smallest of (signed and unsigned) \code{char}, \code{short},
> > + \code{int}, \code{long} and \code{long long} types that can contain
> > + them.
> > + \item For N > 64, they are treated as struct of 64-bit integer
> > + chunks. The number of chunks is the smallest number that can contain
> > + the type.
>
> Suggest an \item here because the following part applies to more than
> just $N > 64$.
>
> > \texttt{_BitInt(N)} types are byte-aligned to the next
> > + greatest power-of-2 up to 64 bits. The size of these types is the
> > + smallest multiple of the 64-bit chunks greater than or equal to N.

Actually, given the first \item says exactly what the size and alignment
are for N <= 64, maybe the second \item should just say "64-bit-aligned"
or "8-byte-aligned" somewhere (along with the information about number of
chunks and size), with no need for any wording about "next greatest
power-of-2 up to 64 bits" at all.

--
Joseph S. Myers
jos...@codesourcery.com

[H.J. Lu]

---
x86-64-ABI/low-level-sys-info.tex | 33 +++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)

diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
index e4fd6d9..9372eb3 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++ b/x86-64-ABI/low-level-sys-info.tex
@@ -274,6 +274,33 @@ but otherwise behave identically. The only exceptions are that

\code{__m128}, \code{__m256} and \code{__m512} must always be aligned
properly.

+\subsubsection{Fundamental Types of N-bit Integers}
+
+\texttt{_BitInt(N)} from ISO/IEC WG14 N2763, where \code{N} is an
+integral constant expression representing the exact number of bits to
+be used to represent the type, is a family of integer types.
+

+\begin{itemize}
+ \item \texttt{_BitInt(N)} types are signed by default, and
+ \texttt{unsigned _BitInt(N)} types are unsigned.
+ \item \texttt{_BitInt(N)} types are stored in little-endian order in

+ memory. Bits in each byte are allocated from bit 0 to bit 7.

+ \item For N <= 64, they have the same size and alignment as
+ the smallest of (signed and unsigned) \code{char}, \code{short},
+ \code{int}, \code{long} and \code{long long} types that can contain
+ them.

+ \item For N > 64, they are treated as struct of 64-bit integer chunks
+ and are aligned to 64 bits. The number of chunks is the smallest
+ number that can contain the type. The size of these types is the

+ smallest multiple of the 64-bit chunks greater than or equal to N.

+ \item The value of the unused bits beyond the width of the
+ \texttt{_BitInt(N)} value but within the size of the
+ \texttt{_BitInt(N)} are unspecified when stored in memory or register.
+\end{itemize}
+
+This permits the use of these types in allocated arrays using the common
+sizeof(Array)/sizeof(ElementType) pattern.
+

\subsubsection{Aggregates and Unions}

Structures and unions assume the alignment of their most strictly

@@ -563,6 +590,12 @@ typedef struct {

[H.J. Lu]

On Mon, Aug 16, 2021 at 10:22 AM Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Sun, 15 Aug 2021, Florian Weimer wrote:
>
> > > +\begin{itemize}
> > > + \item \texttt{_BitInt(N)} types are signed by default, and
> > > + \texttt{unsigned _BitInt(N)} types are unsigned.
> > > + \item \texttt{_BitInt(N)} types are stored in little-endian order in
> > > + memory. Bits in each byte are allocated from right to left.
> >
> > Right to left in register contents, left to right in memory contents, I
> > think.
>
> I don't think "right" and "left" are very helpful terms to use here.

I changed it to "Bits in each byte are allocated from bit 0 to bit 7."

> >
> > > + \item For N <= 64, they have the same size and alignment as
> > > + the smallest of (signed and unsigned) \code{char}, \code{short},
> > > + \code{int}, \code{long} and \code{long long} types that can contain
> > > + them.
> > > + \item For N > 64, they are treated as struct of 64-bit integer
> > > + chunks. The number of chunks is the smallest number that can contain
> > > + the type.
> >
> > Suggest an \item here because the following part applies to more than
> > just $N > 64$.
> >
> > > \texttt{_BitInt(N)} types are byte-aligned to the next
> > > + greatest power-of-2 up to 64 bits. The size of these types is the
> > > + smallest multiple of the 64-bit chunks greater than or equal to N.
>
> Actually, given the first \item says exactly what the size and alignment
> are for N <= 64, maybe the second \item should just say "64-bit-aligned"
> or "8-byte-aligned" somewhere (along with the information about number of
> chunks and size), with no need for any wording about "next greatest
> power-of-2 up to 64 bits" at all.
>

I changed it to

For N > 64, they are treated as struct of 64-bit integer chunks and

are aligned to 64
bits.

Thanks.

--
H.J.

[Florian Weimer]

* H. J. Lu:

>> > > \texttt{_BitInt(N)} types are byte-aligned to the next
>> > > + greatest power-of-2 up to 64 bits. The size of these types is the
>> > > + smallest multiple of the 64-bit chunks greater than or equal to N.
>>
>> Actually, given the first \item says exactly what the size and alignment
>> are for N <= 64, maybe the second \item should just say "64-bit-aligned"
>> or "8-byte-aligned" somewhere (along with the information about number of
>> chunks and size), with no need for any wording about "next greatest
>> power-of-2 up to 64 bits" at all.
>>
>
> I changed it to
>
> For N > 64, they are treated as struct of 64-bit integer chunks and
> are aligned to 64
> bits.

I think we have 128-bit alignment outside of structs (because the object
is 16 bytes large or larger).

Thanks,
Florian

[H.J. Lu]

16-byte alignment is for array, not for struct:

[hjl@gnu-cfl-2 tmp]$ cat y.c
struct foo
{
long long i1;
long long i2;
long long i3;
};

int size = sizeof (struct foo);
int align = __alignof (struct foo);
[hjl@gnu-cfl-2 tmp]$ gcc -S y.c
[hjl@gnu-cfl-2 tmp]$ cat y.s
.file "y.c"
.text
.globl size
.data
.align 4
.type size, @object
.size size, 4
size:
.long 24
.globl align
.align 4
.type align, @object
.size align, 4
align:
.long 8 <<<<<<<<<<<<<<<<<<< 64-bit aligned.
.ident "GCC: (GNU) 11.2.1 20210728 (Red Hat 11.2.1-1)"
.section .note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$

--
H.J.