On Sat, Jan 22, 2022 at 12:15:01PM -0800, Greg Favor wrote:
Recently a PR was sent out to remove U and VU mode standardization from the
platform spec scope. Which is sort of right and sort of wrong.
Could you explain in what way you think it is wrong?
I brought this issue up with Krste and Andrew (especially since this also
relates with the coming RVA Profiles). In short, after significant
discussion, the following can be said:
- Support for the RVA22S64 profile does not directly also require
support for the RVA22U64 profile. Although it does require support for
- BUT, for example, all mandatory ISA extensions in the 'S' profile that
are also in the 'U' profile must be supported not only in S-mode but also
in U-mode. This only excludes ISA extensions that are not relevant to
U-mode, e.g. the Sstc extension. Largely, if not completely, this amounts
to all Unpriv ISA extensions that are required to be supported in S-mode
are also required to be supported in U-mode. The Profile specs will
precisely spell out this and the related matter of "optional supported"
- The OS-A platforms should only mandate the RVA22S64 profile (and not
the RVA22U64 profile as well). U/VU-mode platform requirements will
flow from or be indirectly inherited via the RVA22S64
So I suggest that the change to the platform spec should be something like:
*The current version of this platform spec targets the standardization of
functionality available in S and VS modes (plus the support for U/VU-modes,
and the support for ISA extensions in U/VU modes, as implied by the RVA 'S'
ISA Profile that is mandated by this spec), and the standardization of the
I disagree; I think the parenthetical comment is unnecessary in the
The first portion is explicit in the privileged specification, and the
second portion, and noted, is implied by the extensions mandated for S
mode. Adding this comment as normative text muddies the scope of the
specification: it is standardizing the S-mode interface only. Period.