This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/27] arm64/sve: System register and exception syndrome definitions
On Mon, Aug 21, 2017 at 03:50:32PM +0100, Alex Bennée wrote:
> Dave Martin <Dave.Martin@arm.com> writes:
> > On Mon, Aug 21, 2017 at 01:34:38PM +0100, Alex Bennée wrote:
[...]
> >> > Dave Martin <Dave.Martin@arm.com> writes:
[...]
> >> >> +#define ZCR_ELx_LEN_SHIFT 0
> >> >> +#define ZCR_ELx_LEN_SIZE 9
> >> >> +#define ZCR_ELx_LEN_MASK 0x1ff
> >> >> +
> >>
> >> LEN should be 0/4/0xf
> >>
> >> LEN, bits [3:0]
> >>
> >> Constrains the scalable vector register length for EL1 and EL0 to
> >> (LEN+1)x128 bits.
> >
> > The SVE supplement is not very explicit about the meaning of bits [8:4],
> > but they are reserved to extend the LEN field in the future, in case
> > that's ever needed for future architecture revisions. I've aimed for
> > Linux to cope with this.
> >
> > Basically bits [8:4] are read-as-zero, write-ignore today, but in
> > the future some or all of them may be LEN field bits.
> >
> > In particular, this means that writing all bits [8:0] with 1 will
> > configure the largest supported vector length, even on future
> > architecture versions that may have a larger LEN field.
>
> Ahh ok. It's not clear from the html and it is certainly implied in the
> supplement (2.1.1) that the architectural max is:
>
> The size of every vector register is an IMPLEMENTATION DEFINED
> multiple of 128 bits, up to an architectural maximum of 2048 bits.
>
> >
> > It didn't seem useful to distinguish the two classes of bits here.
>
> Maybe a comment clarifying would be useful then?
OK, I think I can say something like:
/*
* The ZCR_ELx_LEN_* definitions intentionally include bits [8:4]
* which are reserved by the SVE architecture for future expansion of
* the LEN field, with compatible semantics.
*/
Any good?
Cheers
---Dave