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

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?



From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Greg Favor via <>
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


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.


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.

Join { to automatically receive all group messages.