1. Tech-Unixplatformspec
  2. Topics

Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Greg Favor
 

All,

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.

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 U-mode.

  • 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" extensions.

  • 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 profile requirement.

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 SBI (....).

Greg
Darius Rad
 

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
U-mode.

- 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"
extensions.

- 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
profile requirement.


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
SBI (....).*
I disagree; I think the parenthetical comment is unnecessary in the
normative text.

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.

// darius
Greg Favor
 

On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> 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?

That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate.

> *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
> SBI (....).*
>

I disagree; I think the parenthetical comment is unnecessary in the
normative text.

I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec).  One can view the text as also truly a normative part of the spec, or simply as descriptive overview of the scope of the normative spec.

In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality.  Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality.
 
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.

But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality.

But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec.  If one views the scope statement as a normative mandate of the platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment.

Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality.  Since the target of the platform is to support hardware/software interoperability with binary distros, those distros (e.g. Linux) contain U/VU-mode code.  Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes.  Saying that the platform spec only standardizes the S-mode interface can be misleading to readers.  It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality.

Greg
Michael Frank
 

Hi Greg,
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each profile?

Michael



😄
Michael

From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...>
Sent: Monday, January 24, 2022 7:59:22 AM
To: tech-unixplatformspec <tech-unixplatformspec@...>
Cc: Greg Favor <gfavor@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
 

[EXTERNAL EMAIL]

On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> 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?

That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate.

> *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
> SBI (....).*
>

I disagree; I think the parenthetical comment is unnecessary in the
normative text.

I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec).  One can view the text as also truly a normative part of the spec, or simply as descriptive overview of the scope of the normative spec.

In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality.  Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality.
 
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.

But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality.

But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec.  If one views the scope statement as a normative mandate of the platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment.

Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality.  Since the target of the platform is to support hardware/software interoperability with binary distros, those distros (e.g. Linux) contain U/VU-mode code.  Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes.  Saying that the platform spec only standardizes the S-mode interface can be misleading to readers.  It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality.

Greg

To reduce fraud or cyber-crime risks, Arteris IP will never instruct you to change wire payment instructions or bank account details using email or fax. If you receive such an email or fax appearing to be from Arteris IP, please call your Arteris IP’s contact to verify. Please do not verify by email.
Greg Favor
 

On Mon, Jan 24, 2022 at 10:32 AM Michael Frank <Michael.Frank@...> wrote:
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each profile?

The RVA22S64 ISA profile will provide all that detail.  An 2022 OS-A platform spec will simply mandate the RVA22S64 profile.

Greg 

1 - 5 of 5