[PATCH] Assign DWARF register number mapping for AMX registers

16 views
Skip to first unread message

H.J. Lu

unread,
Feb 14, 2024, 7:51:02 AMFeb 14
to x86-6...@googlegroups.com
Assign DWARF register number mapping for Tile and Tile control register.
---
x86-64-ABI/low-level-sys-info.tex | 3 +++
1 file changed, 3 insertions(+)

diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
index ffe23a3..a293a04 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++ b/x86-64-ABI/low-level-sys-info.tex
@@ -2497,6 +2497,7 @@ number mapping for the \xARCH processor family.%
\begin{figure}
\Hrule
\caption{DWARF Register Number Mapping} \label{tbl-reg-num-map}
+\myfontsize
\begin{center}
\begin{tabular}{l|r|l}
\multicolumn{1}{c}{Register Name}&\multicolumn{1}{c}{Number}&\multicolumn{1}{c}{Abbreviation}\\
@@ -2537,6 +2538,8 @@ Reserved & 83-117 & \\
Vector Mask Registers 0--7 & 118-125 & \reg{k0}--\reg{k7} \\
Reserved & 126-129 & \\
APX Integer Registers 16-31 & 130-145 &\reg{r16}--\reg{r31}\\
+Tile Registers 0--7 & 146-153 & \reg{tmm0}--\reg{tmm7} \\
+Tile Control Register & 154 & \reg{tilecfg} \\
\end{tabular}
\end{center}
\Hrule
--
2.43.0

Jan Beulich

unread,
Feb 14, 2024, 8:04:57 AMFeb 14
to H.J. Lu, x86-6...@googlegroups.com
On 14.02.2024 13:50, H.J. Lu wrote:
> Assign DWARF register number mapping for Tile and Tile control register.
> ---
> x86-64-ABI/low-level-sys-info.tex | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
> index ffe23a3..a293a04 100644
> --- a/x86-64-ABI/low-level-sys-info.tex
> +++ b/x86-64-ABI/low-level-sys-info.tex
> @@ -2497,6 +2497,7 @@ number mapping for the \xARCH processor family.%
> \begin{figure}
> \Hrule
> \caption{DWARF Register Number Mapping} \label{tbl-reg-num-map}
> +\myfontsize
> \begin{center}
> \begin{tabular}{l|r|l}
> \multicolumn{1}{c}{Register Name}&\multicolumn{1}{c}{Number}&\multicolumn{1}{c}{Abbreviation}\\

This part looks unrelated.

> @@ -2537,6 +2538,8 @@ Reserved & 83-117 & \\
> Vector Mask Registers 0--7 & 118-125 & \reg{k0}--\reg{k7} \\
> Reserved & 126-129 & \\
> APX Integer Registers 16-31 & 130-145 &\reg{r16}--\reg{r31}\\
> +Tile Registers 0--7 & 146-153 & \reg{tmm0}--\reg{tmm7} \\
> +Tile Control Register & 154 & \reg{tilecfg} \\
> \end{tabular}
> \end{center}
> \Hrule

Just for my own education: There are several holes ("Reserved"), most of
which I can associate with a purpose. What's the reason for not using the
83-117 range (which would have been valid to consider for the APX regs
then as well)?

Jan

H.J. Lu

unread,
Feb 14, 2024, 8:22:54 AMFeb 14
to Jan Beulich, x86-6...@googlegroups.com
On Wed, Feb 14, 2024 at 5:04 AM Jan Beulich <jbeu...@suse.com> wrote:
>
> On 14.02.2024 13:50, H.J. Lu wrote:
> > Assign DWARF register number mapping for Tile and Tile control register.
> > ---
> > x86-64-ABI/low-level-sys-info.tex | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
> > index ffe23a3..a293a04 100644
> > --- a/x86-64-ABI/low-level-sys-info.tex
> > +++ b/x86-64-ABI/low-level-sys-info.tex
> > @@ -2497,6 +2497,7 @@ number mapping for the \xARCH processor family.%
> > \begin{figure}
> > \Hrule
> > \caption{DWARF Register Number Mapping} \label{tbl-reg-num-map}
> > +\myfontsize
> > \begin{center}
> > \begin{tabular}{l|r|l}
> > \multicolumn{1}{c}{Register Name}&\multicolumn{1}{c}{Number}&\multicolumn{1}{c}{Abbreviation}\\
>
> This part looks unrelated.

Without this change, the table is too large and the page number is
inside the table.

>
> > @@ -2537,6 +2538,8 @@ Reserved & 83-117 & \\
> > Vector Mask Registers 0--7 & 118-125 & \reg{k0}--\reg{k7} \\
> > Reserved & 126-129 & \\
> > APX Integer Registers 16-31 & 130-145 &\reg{r16}--\reg{r31}\\
> > +Tile Registers 0--7 & 146-153 & \reg{tmm0}--\reg{tmm7} \\
> > +Tile Control Register & 154 & \reg{tilecfg} \\
> > \end{tabular}
> > \end{center}
> > \Hrule
>
> Just for my own education: There are several holes ("Reserved"), most of
> which I can associate with a purpose. What's the reason for not using the
> 83-117 range (which would have been valid to consider for the APX regs
> then as well)?
>

ZMM registers used separate register mapping at one time. Then later
we decided that XMM mapping is sufficient. The old ZMM mapping
is changed to reserved.

--
H.J.

Jan Beulich

unread,
Feb 14, 2024, 8:35:36 AMFeb 14
to H.J. Lu, x86-6...@googlegroups.com
On 14.02.2024 14:22, H.J. Lu wrote:
> On Wed, Feb 14, 2024 at 5:04 AM Jan Beulich <jbeu...@suse.com> wrote:
>>
>> On 14.02.2024 13:50, H.J. Lu wrote:
>>> Assign DWARF register number mapping for Tile and Tile control register.
>>> ---
>>> x86-64-ABI/low-level-sys-info.tex | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/x86-64-ABI/low-level-sys-info.tex b/x86-64-ABI/low-level-sys-info.tex
>>> index ffe23a3..a293a04 100644
>>> --- a/x86-64-ABI/low-level-sys-info.tex
>>> +++ b/x86-64-ABI/low-level-sys-info.tex
>>> @@ -2497,6 +2497,7 @@ number mapping for the \xARCH processor family.%
>>> \begin{figure}
>>> \Hrule
>>> \caption{DWARF Register Number Mapping} \label{tbl-reg-num-map}
>>> +\myfontsize
>>> \begin{center}
>>> \begin{tabular}{l|r|l}
>>> \multicolumn{1}{c}{Register Name}&\multicolumn{1}{c}{Number}&\multicolumn{1}{c}{Abbreviation}\\
>>
>> This part looks unrelated.
>
> Without this change, the table is too large and the page number is
> inside the table.

Since I don't know what exactly \myfontsize effects, a perhaps odd (to
you) question: Won't this become an issue then later, when yet more
registers appear? Personally I would have expected a formatting tool
to be smart enough to split too large a table across multiple pages
then.

>>> @@ -2537,6 +2538,8 @@ Reserved & 83-117 & \\
>>> Vector Mask Registers 0--7 & 118-125 & \reg{k0}--\reg{k7} \\
>>> Reserved & 126-129 & \\
>>> APX Integer Registers 16-31 & 130-145 &\reg{r16}--\reg{r31}\\
>>> +Tile Registers 0--7 & 146-153 & \reg{tmm0}--\reg{tmm7} \\
>>> +Tile Control Register & 154 & \reg{tilecfg} \\
>>> \end{tabular}
>>> \end{center}
>>> \Hrule
>>
>> Just for my own education: There are several holes ("Reserved"), most of
>> which I can associate with a purpose. What's the reason for not using the
>> 83-117 range (which would have been valid to consider for the APX regs
>> then as well)?
>
> ZMM registers used separate register mapping at one time. Then later
> we decided that XMM mapping is sufficient. The old ZMM mapping
> is changed to reserved.

Hmm, okay. It's not obvious to me why those couldn't be re-used. Plus
it explains only 32 of the 34 values.

Jan

Jan Beulich

unread,
Feb 14, 2024, 8:39:36 AMFeb 14
to H.J. Lu, x86-6...@googlegroups.com
On 14.02.2024 14:22, H.J. Lu wrote:
So binutils-wise, specifying an XMM register in a CFI directive will then
cover all of XMM, YMM, and ZMM. Specifying a YMM or ZMM register in a CFI
directive will not make sense at all, for all their entries uniformly
having Dw2Inval. Shouldn't YMM and ZMM registers then simply use the same
numbers as XMM ones? In source code it'll certainly be more natural to
accompany operations on YMM/ZMM registers with directives mentioning
those, not XMM ones.

Jan

H.J. Lu

unread,
Feb 14, 2024, 8:43:00 AMFeb 14
to Jan Beulich, x86-6...@googlegroups.com
That is a possibility.

> to be smart enough to split too large a table across multiple pages
> then.
>
> >>> @@ -2537,6 +2538,8 @@ Reserved & 83-117 & \\
> >>> Vector Mask Registers 0--7 & 118-125 & \reg{k0}--\reg{k7} \\
> >>> Reserved & 126-129 & \\
> >>> APX Integer Registers 16-31 & 130-145 &\reg{r16}--\reg{r31}\\
> >>> +Tile Registers 0--7 & 146-153 & \reg{tmm0}--\reg{tmm7} \\
> >>> +Tile Control Register & 154 & \reg{tilecfg} \\
> >>> \end{tabular}
> >>> \end{center}
> >>> \Hrule
> >>
> >> Just for my own education: There are several holes ("Reserved"), most of
> >> which I can associate with a purpose. What's the reason for not using the
> >> 83-117 range (which would have been valid to consider for the APX regs
> >> then as well)?
> >
> > ZMM registers used separate register mapping at one time. Then later
> > we decided that XMM mapping is sufficient. The old ZMM mapping
> > is changed to reserved.
>
> Hmm, okay. It's not obvious to me why those couldn't be re-used. Plus
> it explains only 32 of the 34 values.

35, not 34, I don't remember what the other 3 were used for.

> Jan


--
H.J.

H.J. Lu

unread,
Feb 14, 2024, 8:44:01 AMFeb 14
to Jan Beulich, x86-6...@googlegroups.com
Yes.

> accompany operations on YMM/ZMM registers with directives mentioning
> those, not XMM ones.
>
> Jan



--
H.J.

Michael Matz

unread,
Feb 15, 2024, 12:13:41 PMFeb 15
to Jan Beulich, H.J. Lu, x86-6...@googlegroups.com
Hello,

On Wed, 14 Feb 2024, 'Jan Beulich' via X86-64 System V Application Binary Interface wrote:

> > Without this change, the table is too large and the page number is
> > inside the table.
>
> Since I don't know what exactly \myfontsize effects, a perhaps odd (to
> you) question: Won't this become an issue then later, when yet more
> registers appear? Personally I would have expected a formatting tool
> to be smart enough to split too large a table across multiple pages
> then.

Our collective LaTeX foo is not strong enough for that :-)
You're welcome to investigate and try (because I agree, it's probably
possible).


Ciao,
Michael.

Florian Weimer

unread,
Feb 15, 2024, 3:00:35 PMFeb 15
to 'Jan Beulich' via X86-64 System V Application Binary Interface, H.J. Lu, Jan Beulich
* via:

> Since I don't know what exactly \myfontsize effects, a perhaps odd (to
> you) question: Won't this become an issue then later, when yet more
> registers appear? Personally I would have expected a formatting tool
> to be smart enough to split too large a table across multiple pages
> then.

In the past, there was the longtable LaTeX package for that. I don't
know if that's still the recommended way, though.

Thanks,
Florian

H.J. Lu

unread,
Feb 21, 2024, 12:27:52 PMFeb 21
to Florian Weimer, 'Jan Beulich' via X86-64 System V Application Binary Interface, Jan Beulich
Any objections to the patch:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/54


--
H.J.

H.J. Lu

unread,
Feb 22, 2024, 9:33:51 AMFeb 22
to Florian Weimer, 'Jan Beulich' via X86-64 System V Application Binary Interface, Jan Beulich
I will merge it tomorrow.

--
H.J.
Reply all
Reply to author
Forward
0 new messages