Re: [PATCH,v2 17/17] [gdb/docs] sme: Document SME registers and features

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

> Date: Thu, 13 Apr 2023 17:34:17 +0100
> Cc: gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> I may have made a few mistakes before using lower case svq and svl, which should now be
> fixed in the upcoming version. Before I send an update though, I'd like to clarify
> the terminology and how I'm using it. Just a sanity check that it isn't confusing still.
> 
> SVG, SVQ and SVL (upper case) are only definitions for SME. SVL is the vector size in bytes,
> SVG is SVL / 8 and SVQ is SVL / 16. All of them are vector sizes, but with different
> granularities.
> 
> GDB exposes the SME vector size SVG as the svg (lower case) register, so users can check the
> current vector size and change it if they want.
> 
> In the end, we have 3 definitions and a register.
> 
> Does that make sense?

I understand the terminology you want to use.

> > My main point was that it is easier and clearer to say ABCxABC than to
> > use some unrelated symbol N and then explain that N equals to the
> > parameter ABC.  But it's a minor issue.
> > 
> 
> That's fair. I find that slightly confusing too. What we should say, based on the
> SME vector size definitions above is:
> 
> The @code{za} register is a 2-dimensional square
> @code{@var{SVL}x@var{SVL}} matrix of bytes.
> 
> That makes it clear and obvious (to me) that we have a matrix of size
> SVL x SVL bytes.

Yes, but please note that the argument of @var should a lower-case
word.  In Info format, it is up-cases, but in HTML and PDF it's
typeset in slant typeface, and not up-cased.

This is actually one place where using SVL and SVG as parameters gets
in the way: you spell them in upper-case, which is against the
practice of using @var.

> > Then please say that without using the word "same" on its own.  "Same"
> > begs the question "same as what?", which doesn't have an answer in
> > this context.
> >
> 
> Ok. I think something like the following might address your concerns?
> 
> Attempting to set the @code{svg} register value to its current value will have no effect.

Yes, this is okay.

Thanks.