1. Tech-Unixplatformspec
  2. Topics

Platform naming question

Greg Favor
 

An issue is being raised in RVI over the overloaded naming of arch features, profile names, and platform names using "M".  At an arch level, M mode is officially established.  But then there are RVM* profiles and M platforms.

The request I was asked to pass down to the Platforms group is to come up with a different name for the "M" platforms.  It would be desirable to at least switch to a different tentative name, even if finalizing a name is kicked down the road for a little while.

For context, the "M" platforms are intended for non-"Rich OS" system designs, e.g. designs running bare metal or with an RTOS (versus a Linux-class OS).

So, to throw out some ideas, what about "Embedded" (although there are also embedded Linux-based systems), or "Microcontroller" (which maybe is too narrow?), or "OS-M" (which strays partially back to overloaded use of "M").  Or ???

Greg
Darius Rad
 

On Wed, Oct 20, 2021 at 11:47:58AM -0700, Greg Favor wrote:

So, to throw out some ideas, what about "Embedded" (although there are also
embedded Linux-based systems), or "Microcontroller" (which maybe is too
narrow?), or "OS-M" (which strays partially back to overloaded use of
"M"). Or ???
How about "Bare-M"? It evokes the idea of bare metal applications, in
contrast to (rich) operating systems, and keeps the "M" for the association
with M-mode and microcontrollers.

If <anything>-M is objectionable, then I would imagine OS-A would be
similarly problematic for the "A" association, as there is an "A" extension
as well as a forthcoming "A" profile.

// darius
Greg Favor
 

On Wed, Oct 20, 2021 at 1:23 PM Darius Rad <darius@...> wrote:
If <anything>-M is objectionable, then I would imagine OS-A would be
similarly problematic for the "A" association, as there is an "A" extension
as well as a forthcoming "A" profile.

People have not expressed confusion over the more limited overloading of "A".  Plus the profile use of "A" and the platform use of "A" are meant to both refer to Application-class designs (somewhat analogous to A-class CPUs and the ARMv8-A architecture in the ARM world).  So the only overload is between the A extension and these other uses of "A".  The main point of confusion for some people appears to be between profile use of "M" and platform use of "M" and the frequent references to M-mode in profiles and platforms.

Greg
Allen Baum
 

You probably don't want to use "U" (or µ). If we have to pick an Ascii character, "E" could work, since RV32E architectures are intended for microcontroller implementations.

On Wed, Oct 20, 2021 at 2:09 PM Greg Favor <gfavor@...> wrote:
On Wed, Oct 20, 2021 at 1:23 PM Darius Rad <darius@...> wrote:
If <anything>-M is objectionable, then I would imagine OS-A would be
similarly problematic for the "A" association, as there is an "A" extension
as well as a forthcoming "A" profile.

People have not expressed confusion over the more limited overloading of "A".  Plus the profile use of "A" and the platform use of "A" are meant to both refer to Application-class designs (somewhat analogous to A-class CPUs and the ARMv8-A architecture in the ARM world).  So the only overload is between the A extension and these other uses of "A".  The main point of confusion for some people appears to be between profile use of "M" and platform use of "M" and the frequent references to M-mode in profiles and platforms.

Greg

1 - 4 of 4