[PATCH] Add optional _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..34c4e08 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{Optional 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 and unsigned types are
+ \texttt{unsigned _BitInt(N)}.
+ \item \texttt{_BitInt(N)} types are stored in little-endian order in
+ memory.
+ \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 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 bit-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

[Michael Matz]

Hello,

On Mon, 9 Aug 2021, H.J. Lu wrote:

What's the voting status for N2763? I.e. is it perhaps too early to add
it to the psABI, or just the right time?

> +\subsubsection{Optional 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 and unsigned types are
> + \texttt{unsigned _BitInt(N)}.
> + \item \texttt{_BitInt(N)} types are stored in little-endian order in
> + memory.

As this touches bit-fields we probably also need to say something about
how bits are allocated, not just the bytes, maybe just by referring to the
bit-fields section earlier.

> + \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 treated as struct of 64-bit integer

+ "are"

> + chunks. The number of chunks is the smallest number that can contain
> + the type. \texttt{_BitInt(N)} types are bit-aligned to the next
> + greatest power-of-2 up to 64 bits.

I have difficulties to interpret this, also in the N2763 document: apart
from the placement above (the document specifies this also for the smaller
than 64bit type) what is "bit-aligned" supposed to mean, exactly? E.g.
for a _BitInt(4) type, the bit-alignment, as specified, will be 4. The
bit size will be 4 as well (and sizeof will be 1). Of course that's not a
whole byte, which normally is the smallest unit of alignment. So we have
a bit alignment of "4" now, does this mean that two successive fields of
that type will share a byte? What about an array of these types? Can you
or can you not address individual elements of them? (Same question for
address of struct members with these types).

FWIW, I don't see how such bit alignment with the obvious meaning (i.e.
resulting in tight packing) could be implemented: there is a reason why
addresses of bit fields can't be taken, the addresses aren't expressible
in whole units.

So, I think something is amiss with the n2763 document regarding alignment
of _BitInt(N) with N < 8. (For larger BitInts the alignment and size will
always be multiple of 8 bits (in fact always be power of 2 >= 8), so don't
have the issue above).


Ciao,
Michael.

[Joseph Myers]

On Tue, 10 Aug 2021, Michael Matz wrote:

> What's the voting status for N2763? I.e. is it perhaps too early to add
> it to the psABI, or just the right time?

N2709 (first alternative) was accepted at the June WG14 meeting, with
minor wording changes. N2763 serves to document what those changes were.

> I have difficulties to interpret this, also in the N2763 document: apart
> from the placement above (the document specifies this also for the smaller
> than 64bit type) what is "bit-aligned" supposed to mean, exactly? E.g.
> for a _BitInt(4) type, the bit-alignment, as specified, will be 4. The
> bit size will be 4 as well (and sizeof will be 1). Of course that's not a
> whole byte, which normally is the smallest unit of alignment. So we have
> a bit alignment of "4" now, does this mean that two successive fields of
> that type will share a byte? What about an array of these types? Can you
> or can you not address individual elements of them? (Same question for
> address of struct members with these types).

_BitInt types are normal C types occupying an integer number of bytes (and
having padding bits when those bytes contain more bits than specified as
an argument to _BitInt), which can be used for addressable objects (each
having its own address) just like other types.

The types are quite similar to what you get in GCC with code such as

#define _BitInt(n) __typeof__(0, (struct { __int128 __x : n; }){ 0 }.__x)

except that such constructs involving bit-field types escaping from their
containing structs have no defined ABI for the types in question, do not
follow the special integer promotion rules of _BitInt, and do not follow
the rule disallowing a signed _BitInt(1).

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

[Michael Matz]

Hello,

On Tue, 10 Aug 2021, Joseph Myers wrote:

> > What's the voting status for N2763? I.e. is it perhaps too early to add
> > it to the psABI, or just the right time?
>
> N2709 (first alternative) was accepted at the June WG14 meeting, with
> minor wording changes. N2763 serves to document what those changes were.
>
> > I have difficulties to interpret this, also in the N2763 document: apart
> > from the placement above (the document specifies this also for the smaller
> > than 64bit type) what is "bit-aligned" supposed to mean, exactly? E.g.
> > for a _BitInt(4) type, the bit-alignment, as specified, will be 4. The
> > bit size will be 4 as well (and sizeof will be 1). Of course that's not a
> > whole byte, which normally is the smallest unit of alignment. So we have
> > a bit alignment of "4" now, does this mean that two successive fields of
> > that type will share a byte? What about an array of these types? Can you
> > or can you not address individual elements of them? (Same question for
> > address of struct members with these types).
>
> _BitInt types are normal C types occupying an integer number of bytes (and
> having padding bits when those bytes contain more bits than specified as
> an argument to _BitInt), which can be used for addressable objects (each
> having its own address) just like other types.

Okay, as expected then. Then please interpret the phrases involving the
term "bit-alignment" in that light.


Ciao,
Michael.

[H.J. Lu]

On Tue, Aug 10, 2021 at 8:52 AM Michael Matz <ma...@suse.de> wrote:
>
> Hello,
>
> On Tue, 10 Aug 2021, Joseph Myers wrote:
>
> > > What's the voting status for N2763? I.e. is it perhaps too early to add
> > > it to the psABI, or just the right time?
> >
> > N2709 (first alternative) was accepted at the June WG14 meeting, with
> > minor wording changes. N2763 serves to document what those changes were.
> >
> > > I have difficulties to interpret this, also in the N2763 document: apart
> > > from the placement above (the document specifies this also for the smaller
> > > than 64bit type) what is "bit-aligned" supposed to mean, exactly? E.g.
> > > for a _BitInt(4) type, the bit-alignment, as specified, will be 4. The
> > > bit size will be 4 as well (and sizeof will be 1). Of course that's not a
> > > whole byte, which normally is the smallest unit of alignment. So we have
> > > a bit alignment of "4" now, does this mean that two successive fields of
> > > that type will share a byte? What about an array of these types? Can you
> > > or can you not address individual elements of them? (Same question for
> > > address of struct members with these types).
> >
> > _BitInt types are normal C types occupying an integer number of bytes (and
> > having padding bits when those bytes contain more bits than specified as
> > an argument to _BitInt), which can be used for addressable objects (each
> > having its own address) just like other types.
>
> Okay, as expected then. Then please interpret the phrases involving the
> term "bit-alignment" in that light.

I sent out the v2 patch to address all issues raised.

Thanks.

>
> Ciao,
> Michael.
>
> > The types are quite similar to what you get in GCC with code such as
> >
> > #define _BitInt(n) __typeof__(0, (struct { __int128 __x : n; }){ 0 }.__x)
> >
> > except that such constructs involving bit-field types escaping from their
> > containing structs have no defined ABI for the types in question, do not
> > follow the special integer promotion rules of _BitInt, and do not follow
> > the rule disallowing a signed _BitInt(1).
> >
> >

--
H.J.