Date
1 - 4 of 4
Platform specs and M/S/U levels of requirements
|
Greg Favor
Yesterday the Arch Review committee (including most notably Krste and Andrew) discussed the issue raised over the past week and in Monday's Platforms group meeting - as part of a more general discussion about the expected structuring of ISA profiles and platforms. I was asked to write up and convey the results. First, for context, just like there are multiple RISC-V ISA profiles, there will be multiple RISC-V platforms. Taking for example the RVA22 profile, this is actually three distinct profiles representing M, S, and U functionality. One can choose to be compliant with one, two, or all three RVA22 profiles. Similar is true for all the other profiles. Over time there will be multiple "M" platforms and multiple "OS-A" platforms (i.e. there is not just one "OS-A" platform). Further, there will be updated profiles and platforms every year or two (leaving aside the details). To start there are two OS-A platforms in the works (with more to be started next year). The "base/basic" platform (which is expected to be renamed) is intended to provide a broad tent for many types of "rich OS" designs to be able to comply with. (Although the tension still remains between setting a low bar that standardizes and requires less and setting a higher bar that standardizes and requires more. No matter what, not everyone will be happy with this or any particular platform. Which is part of why there will be other platforms as well.) The "server" platform (also expected to be renamed to avoid improper connotations) will be the first of many more targeted platforms (addressing broad market areas like automotive, HPC, mobile/Android, "server", etc.) that by their nature standardize and require more and set a higher bar. Some platforms may choose to build on top of another existing platform spec; others may be their own completely independent platform. For the "basic" platform there should be separate M and S/U platforms (roughly akin to the profile situation). One can claim compliance and branding with just the "OS-A Basic-SU" platform (the actual name tbd), or with both the "OS-A Basic-SU" and "OS-A Basic-M" platforms. Tbd whether the latter is solely an "extension or add-on platform" to the former, or is a separate platform that can be used with other "OS-A XXX-SU" platforms as well. Ditto for other "OS-A XXX-M" platforms that are developed. And for that matter a more targeted platform may choose to standardize M as well as S and U levels as one platform. "OS-A SU" platforms are focused on providing OS/User interoperability between hardware and software (whether binary or source interoperability - depending on the particular platform in question). "OS-A M" platforms are focused on M-level source interoperability for certain components of M-mode software. An initial "OS-A M" platform would focus on enabling hardware/software source interoperability just for OpenSBI and similar SBI implementations. Further "OS-A M" platforms will reflect new and growing RISC-V M-level standards in areas like security and focus on enabling a broader range of M-mode hardware/software interoperability (although there will always be platform-specific M-mode software). In short, as far as the recent discussions about the "OS-A Basic" platform, the "OS-A Basic" platform should really be separated into two pieces. The "OS-A Basic-SU" platform (until a better and more appropriate name is determined) addresses what a number of people have been desiring and arguing for. The "OS-A Basic-M" platform is available for people that want to also comply with that. While others will choose to comply with just the "OS-A Basic-SU" platform. (Providing, just like the ISA profiles, flexibility for a variety of system implementations. Which will increase as more platforms are developed.) Greg |
|
|
|
Darius Rad
On Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote:
With platforms as the analog to profiles, where is there not a similar analog below platforms as there are extensions below profiles? For example, I can easily describe an RV64IMA system, which likely won't be part of a standard profile, by invoking the standard I, M, and A extensions. Why can I not do something similar for platforms? I would like to. ...What is the motivation for combining S and U mode, as opposed to having them split? Split seems to make more sense to me, since for example, each operating system will likely have significant differences at the U level interface, but could share the same S level interface. The vast majority of the existing draft OS-A specification deals with S level details anyway, and what details exist for the U level interface are far from complete. If we consider the comment above about having an analog to ISA-extensions for platforms, we could have common sub-platform elements that are shared for different operating systems (like the ELF, DWARF, and psABI details) as well as other sub-platform elements that are operating system specific (e.g., Linux user mode ABI, BSD user mode ABI, etc.). // darius |
|
|
|
andrew@...
On Wed, Oct 20, 2021 at 1:41 PM Darius Rad <darius@...> wrote: On Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote: The intent is not to encode the ABI in this profile; rather, it's the interface that OS distributions should target. Exactly what we name this thing is perhaps debatable.
|
|
|
|
Darius Rad
On Wed, Oct 20, 2021 at 02:14:38PM -0700, Andrew Waterman wrote:
On Wed, Oct 20, 2021 at 1:41 PM Darius Rad <darius@...> wrote:Yet there is a section titled "Software and ABIs" in the currentOn Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote:The intent is not to encode the ABI in this profile; rather, it's thethere draft, which would suggest otherwise. If we consider the comment above about having an analog to ISA-extensions |
|
|