Expanding RISC-V instruction-set namespace

[Krste Asanovic]

I'm posting this proposal here as the issues cut across a few groups,
and it would be good to have wider propagation and discussion around
the expansion,

Krste


This proposal expands the namespace for RISC-V standard
instruction-set extensions and provides finer-grain grouping of the
existing instructions.

Motivation
----------

The current RISC-V standard instruction-set namespace consists of 26
single-letter names, and each letter typically corresponds to a
relatively large number of instructions. While this has worked well
to concisely specify the initial set of extensions and to convey the
concept of a modular instruction set, there is a need for a larger
instruction-set namespace to accomodate future instruction-set
extensions.

Also, the current ISA specification was written with a variety of
platform and ABI/SBI constraints folded into the instruction
specifications, whereas we would now like to separate instruction
specifications from platform profiles and ABI/SBI specifications.
This separation both enables more freedom to reuse existing
instruction specifications in different types of platform and ABI/SBI,
while allowing the platform profiles and ABI/SBI to more tightly
constrain implementations to simplify software development and
testing.

Proposal
--------

The proposal is to use multicharacter names beginning with Z to expand
the namespace for standard extensions, for example, Zftrig to name the
ftrig extension. This follows the existing pattern for the X
extensions, which are used to name non-standard extensions. As with X
extensions, underscores are used in an ISA name string to separate Z
names from other components, and instruction-set names are
case-insensitive.

Single-letter name categories
-----------------------------

All Z instruction-set names begin with a single letter that indicates
the category of the extension. All existing single-letter names
retain their existing meaning, and are given alternate names in the Z
namespace of Z followed by the single letter, e.g., Za == A. Each
existing single letter name is now also considered to name a category,
and additional instruction-set extensions can be added to the existing
single-letter categories, e.g., Zftrig. The unallocated single-letter
names are now reserved for future instruction-set categories, rather
than a single fixed extension.

Representing individual instructions
------------------------------------

Individual instructions within an existing single-letter extension are
named by preceding the instruction name with the single letter of the
extension, e.g.

Zilui
Ziauipc
Zijal
Zijalr
..
Zilwu
..
Zisraw
Zmmul
Zmmulh
Zmdiv
Zmrem
..
Zalrw
Zascw
Zaamoswapw
...
Zfflw
...
Zfcvtdwu
..
Zdfld
..
Zdfmvdx

Pseudo-instructions that represent a restricted encoding of a given
instruction are also named, e.g.,

Zirdinstret
Zirdcycle
Zirdtime

Representing new subsets
------------------------

New subsets of the existing instruction-set extensions are also
defined, e.g.,

Zaamo refers to all the AMO instructions in the A extension.

Zalrsc refers to the LR/SC instructions in the A extension.

As with other extensions, the preceding base (RV32/RV64/RV128) and
extensions can modify which instructions are indicated by these names.

Representation in machine ISA register misa
-------------------------------------------

The meaning of the misa CSR is unchanged for the existing defined bits
(ACDEFHIMQSU), where each set bit indicates that the currently defined
set of instructions in the corresponding letter category are all
supported.

Currently reserved bits in the lower 25 bits will in future be used to
indicate the basic set of instructions in each new category are
implemented (e.g., V for base vector extension).

If the Z bit is set, there may be additional standard instructions
defined in each category.

The G bit will be used to indicate there are additional instruction .

More detailed information about the instructions supported in hardware
can be provided at the platform level (e.g., in ROM), and communicated
via SBI/ABI calls to software.

Detailed listing of existing allocated names
--------------------------------------------

A canonical list will be maintained of allocated names in the
instruction namespace, as part of the opcode-space managment TG.

TBD

[Krste Asanovic]

One line was cut off, editing below.
Krste

^categories.

[Alex Bradbury]

On 15 November 2017 at 02:12, Krste Asanovic <kr...@berkeley.edu> wrote:
> Representing new subsets
> ------------------------
>
> New subsets of the existing instruction-set extensions are also
> defined, e.g.,
>
> Zaamo refers to all the AMO instructions in the A extension.
>
> Zalrsc refers to the LR/SC instructions in the A extension.
>
> As with other extensions, the preceding base (RV32/RV64/RV128) and
> extensions can modify which instructions are indicated by these names.
>
> Representation in machine ISA register misa
> -------------------------------------------
>
> The meaning of the misa CSR is unchanged for the existing defined bits
> (ACDEFHIMQSU), where each set bit indicates that the currently defined
> set of instructions in the corresponding letter category are all
> supported.
>
> Currently reserved bits in the lower 25 bits will in future be used to
> indicate the basic set of instructions in each new category are
> implemented (e.g., V for base vector extension).
>
> If the Z bit is set, there may be additional standard instructions
> defined in each category.
>
> The G bit will be used to indicate there are additional instruction .
>
> More detailed information about the instructions supported in hardware
> can be provided at the platform level (e.g., in ROM), and communicated
> via SBI/ABI calls to software.

Do you have any thoughts on, for instance, representing cases where
rdcycle/rdinstret/rdtime are not implemented? Or is the expectation
that you'd describe such as a system as RV32I M-mode only (how to
describe that in an ISA string? let's call it $M_mode_only_RV32I for
now), and M-mode implementations that _did_ provide those
pseudoinstructions would be $M_mode_only_RV32I with
ZirdcycleZirdinstretZirdtime? Do you imagine defining a Zi<foo>
specifier to indicate that unaligned loads/stores trap, or would you
imagine that information is specified through some other mechanism?

Currently, implementers who support multiply instructions in the M
extensions but not divide would pass -march=rv32im and -mno-div to the
compiler. As I understand it, this proposal is trying to ensure that
extensions remain purely additive, so you wouldn't have an RV32IM with
Zmnodiv and platforms that don't provide divide instructions (either
in hardware or trapped+emulated by the runtime) would best be
described as something like RV32I with Zmmulinsts (defining Zmmulinsts
to imply Zmmul, Zmmulh, Zmmulhsu, Zmmulhu). Is that right?

Best,

Alex

[kr...@berkeley.edu]

>>>>> On Wed, 15 Nov 2017 08:03:06 +0000, Alex Bradbury <a...@asbradbury.org> said:
| Do you have any thoughts on, for instance, representing cases where
| rdcycle/rdinstret/rdtime are not implemented?

| Or is the expectation that you'd describe such as a system as RV32I
| M-mode only (how to describe that in an ISA string? let's call it
| $M_mode_only_RV32I for now), and M-mode implementations that _did_
| provide those pseudoinstructions would be $M_mode_only_RV32I with
| ZirdcycleZirdinstretZirdtime? Do you imagine defining a Zi<foo>
| specifier to indicate that unaligned loads/stores trap, or would you
| imagine that information is specified through some other mechanism?

This name expansion is part of a drive towards ratifying the base
spec, which uncovers a few issues caused by not separating out the
different places where the supported instruction set needs to be
defined.

There are (at least) two different types of supported instruction-set
specification needed:

1) platform profiles: a description of what a real hardware platform
must actually implement (and what would be present in a hardware
advertisment).

2) EEBIs: (execution-environment binary interfaces) describing how
software should be encoded for a given execution environment, with
examples being the current ABI and SBI specs.

The Foundation needs to standardize both kinds of spec. Note that
multiple EEBIs can run on one hardware platform.

The current user ISA spec does not distinguish between these cases,
and also encodes some EEBI/platform mandates in the base
instruction-set specifications. For example, the current "user" ISA
spec cannot be used as an "unprivileged" ISA spec, as some features
(e.g., misaligned accesses) are assumed to be often emulated by an EE.
We do need to factor out platform and EEBI constraints from the
instruction-set specifications. The primary goal here is to allow a
given instruction specification to be usable in many different
platform and EEBI specs, and at different privilege levels.

The current ISA naming convention is a better fit for EEBI specs as it
is coarse-grained and glosses over whether a feature is emulated or
not at various privilege levels, which makes it less suitable to use
for detailed hardware platform specs.

Your questions above are actually mostly related to a hardware
platform spec. To indicate an M-only platform, the convention would
be to not include lesser-privilege-mode indicators (HSU) in the ISA
string for the hardware platform (and to include them when they are
supported). As we get into more detailed questions, like do misaligned
memory accesses trap, it will be very difficult to encode all the
hardware choices in a simple standard string (e.g.., they only trap
when crossing a 4KiB page boundary, or only when the TLB misses on any
part of the access etc.). At some point, this level of detail has to
be represented in a platform config string / device tree of some kind.
In practice, most software just needs to know whether to emit separate
code for misaligned accesses or not (so, "yes" if all misaligned
accesses trap, and "no" if only traps when TLB misses on a part).

Another concern is that we require extensions to only increase
capability not remove functionality, so we cannot add
"Zimisaligntraps" as a standard extension to the ISA string. Neither
do we want to remove "I" specifier from trap-on-misalign
implementations. I think for platform specs, we can treat the ISA
string as an approximation of the platform capabilities, where the
deciding line is whether trap-and-emulate is sufficient to provide the
expected functionality and performance level of each instruction such
that the common ABIs on the platform would run reasonably well. So, a
hardware platform should be able to claim to support F and D even if
subnormals cause traps.

But I don't think capturing detailed hardware platform specs is really
the main issue you're worrying about here. I think the important
issues relate to a) providing a compatible ABI across various M-only
systems and b) tuning M-only code for a given hardware platform. ISA
strings for EEBIs should be exact, as in exactly these instructions
can be used by code for this ABI, but an M-only ABI could state that
misaligned accesses are illegal for example, as most implementations
will not have hardware support and will trap, and most M-only
applications will not need or want misaligned accesses to be trapped
and emulated. An M-only ABI can also state that divide instructions
are supported, and so a given system lacking a hardware divider must
provide emulation for divide instructions, but is also free to use the
compiler flag to generate software divide function calls instead to
accelerate code for that target.

For the cycle/iret/time counters, the current user spec was written to
mandate these are present for user-mode code (i.e., the U-mode ABI).
We need to decide if these are mandatory for M-only hardware platforms
when we ratify for Foundation. Another complication is that we
removed these from RV32E, but then said RV32E could add U mode. My
inclination is to say the counters must be supported in U/S/H-mode
(including RV32EU), but are optional in M-only platforms.

Of course, this is all separate from EEBIs, where a M-only ABI spec
could mandate counters are present.

Similarly, we could say misaligned support was not mandatory for
M-only platforms and maybe add a Zimisalign extension to announce
where the hardware did support it. The confusing thing is that
Zmisalign could be implicit in a U ABI spec, but might be explicit in
an U-capable platform spec.

| Currently, implementers who support multiply instructions in the M
| extensions but not divide would pass -march=rv32im and -mno-div to the
| compiler. As I understand it, this proposal is trying to ensure that
| extensions remain purely additive, so you wouldn't have an RV32IM with
| Zmnodiv and platforms that don't provide divide instructions (either
| in hardware or trapped+emulated by the runtime) would best be
| described as something like RV32I with Zmmulinsts (defining Zmmulinsts
| to imply Zmmul, Zmmulh, Zmmulhsu, Zmmulhu). Is that right?

Right - though maybe use the shorter name Zmul (Zm + ul) to describe
that set (so, "RV32I_Zmul" would be a common configuration). But
staying compatible with other gcc targets is also important, so I
would propose we keep existing "-mno-div" flag.

It is worth discussing if we want to have negative extensions "Zno---"
to simplify compiler command strings.

In the current compiler command lines, the -mabi argument doesn't
actually specify the complete ABI, as the -march string separately
indicates which instructions to use.

Krste


| Best,

| Alex

[David Horner]

Is this intended to supersede User Manual section 22.4 Version Numbers?

> The G ISA subset
> can be written as “RV64I2p0M2p0A2p0F2p0D2p0”, or more concisely “RV64G2”.
Or is this proposal orthogonal to it. There is of course some
overlap/correlation.

In either case, will we define G (in RV64G, say) to be = IMAFDSU =
Za_Zd_Zf_Zi_Zm_Zs_Zu ?

more questions in context below:

On 2017-11-15 06:53 AM, krste wrote:
> | this proposal is trying to ensure that
> | extensions remain purely additive, so you wouldn't have an RV32IM with
> | Zmnodiv and platforms that don't provide divide instructions (either
> | in hardware or trapped+emulated by the runtime) would best be
> | described as something like RV32I with Zmmulinsts (defining Zmmulinsts
> | to imply Zmmul, Zmmulh, Zmmulhsu, Zmmulhu). Is that right?
>
> Right - though maybe use the shorter name Zmul (Zm + ul) to describe
> that set (so, "RV32I_Zmul" would be a common configuration).

The convention is definitive to enumerating individual instructions (
"Z" + category + instruction_name).
However, as illustrated by Zmul, in general defining grouping of
instructions is more arbitrary.
Are we anticipating that the canonical listing will attempt to maintain
the groups in a strict hierarchy of sub-groups?
I say attempt, because I expect it will be impractical for the purposes
mentioned.
Convenience in providing convenient names for common use cases likely
will conflict.

> But staying compatible with other gcc targets is also important, so I
> would propose we keep existing "-mno-div" flag.
>
> It is worth discussing if we want to have negative extensions "Zno---"
> to simplify compiler command strings.

I'd suggest ZZ prefix for such negative extensions which will avoid
namespace collision (N extension in this case).

And how does this jive with earlier in the email:

> Another concern is that we require extensions to only increase
> capability not remove functionality, so we cannot add
> "Zimisaligntraps" as a standard extension to the ISA string. Neither
> do we want to remove "I" specifier from trap-on-misalign
> implementations.

If the ZZmisalignmaytrap is in "i" , then specific implementations can
add Zimisalign.
Or add Zamisalign for AMO set etc..
I'd suggest the ZZ...maytrap identifiers be explicit in the definitions,
but they may be part of the base definition for all categories.

> I think for platform specs, we can treat the ISA
> string as an approximation of the platform capabilities, where the
> deciding line is whether trap-and-emulate is sufficient to provide the
> expected functionality and performance level of each instruction such
> that the common ABIs on the platform would run reasonably well.

I expect in practice this will be impossible to determine for all use
cases, rather we should make such concern explicit.
e.g. ZaAMOmaytrap and augment with ZaAMOdirectExecute when LRSC
emulation not used.
I agree that the level of hardware implementation specific details is
important.
For instance I do not expect we should create
ZaAMOmayMicroCodeEmulateWithLR

SC , but rather include such in
ZaAMOmaytrap and if necessary allow a ZaAMOMicroCoded if the
implementation does provide a significant performance difference.
And of course, ZaAMOwithMemorySupport when amo is performed in the
memory subsystem.
Perhaps this is best in "platform config string / device tree" rather
than a instruction set Z qualifier.

This AMO example illustrates the difficulty in determining "expected
functionality and performance level" for different use cases.
Software could well take a different approach in locking if each AMO is
MicroCoded vs knowing it could use InMemoryAMOAssist.

> So, a
> hardware platform should be able to claim to support F and D even if
> subnormals cause traps.

Here I would recommend ZZsubnornalsmaytrap be explicitly part of the
FDQV standard, overridden by a Zfsubnormals, etc .

[Jacob Bachmeyer]

Krste Asanovic wrote:
> Proposal
> --------
>
> The proposal is to use multicharacter names beginning with Z to expand
> the namespace for standard extensions, for example, Zftrig to name the
> ftrig extension. This follows the existing pattern for the X
> extensions, which are used to name non-standard extensions. As with X
> extensions, underscores are used in an ISA name string to separate Z
> names from other components, and instruction-set names are
> case-insensitive.
>

I like this, especially the option for expanded sub-extensions.

> Single-letter name categories
> -----------------------------
>
> All Z instruction-set names begin with a single letter that indicates
> the category of the extension. All existing single-letter names
> retain their existing meaning, and are given alternate names in the Z
> namespace of Z followed by the single letter, e.g., Za == A. Each
> existing single letter name is now also considered to name a category,
> and additional instruction-set extensions can be added to the existing
> single-letter categories, e.g., Zftrig. The unallocated single-letter
> names are now reserved for future instruction-set categories, rather
> than a single fixed extension.
>

I suggest that Za be the A category, while A remains specifically the
RVA atomic memory extension. This also leads to a counter-proposal I
mention below.

This could create very long names; would these generally be implied and
used only to indicate the presence of a few instructions from a larger
extension?

> Representing new subsets
> ------------------------
>
> New subsets of the existing instruction-set extensions are also
> defined, e.g.,
>
> Zaamo refers to all the AMO instructions in the A extension.
>
> Zalrsc refers to the LR/SC instructions in the A extension.
>
> As with other extensions, the preceding base (RV32/RV64/RV128) and
> extensions can modify which instructions are indicated by these names.
>
> Representation in machine ISA register misa
> -------------------------------------------
>
> The meaning of the misa CSR is unchanged for the existing defined bits
> (ACDEFHIMQSU), where each set bit indicates that the currently defined
> set of instructions in the corresponding letter category are all
> supported.
>
> Currently reserved bits in the lower 25 bits will in future be used to
> indicate the basic set of instructions in each new category are
> implemented (e.g., V for base vector extension).
>
> If the Z bit is set, there may be additional standard instructions
> defined in each category.
>

So misa.Z is set to indicate the presence of "loose instructions"?

> The G bit will be used to indicate there are additional instruction categories.
>

Do I understand correctly that misa.G indicates the presence of
"long-name" extensions, while misa.Z indicates individual instructions
indicated with the "Z" syntax?

> More detailed information about the instructions supported in hardware
> can be provided at the platform level (e.g., in ROM), and communicated
> via SBI/ABI calls to software.
>

========================================

For discussion, I offer a counter-proposal that all single-letter names
be changed to categories, with current extensions as "baselines" for
their categories. In this proposal, Zftrig for trigonometry
instructions would instead be simply Ftrig and would be implied for an
implementation that supports Dtrig or Qtrig. Similarly, "A" continues
to indicate the RVA atomic memory access extension, but "Aamo" and
"Alrsc" would be distinct names for the AMO and LR/SC subsets. An
implementation with both subsets simply implements "A". Underscores are
used canonically to separate multi-character extension names, but since
extension names are lowercase and categories uppercase, missing
underscores do not create ambiguity.

Further, the standard way to refer to an extension "X" in the abstract
would be "RVX"; this is unambiguous with respect to full descriptions
since those always begin with "RV" and a width. So the floating-point
trigonometry instructions would be RVFtrig, RVDtrig, and RVQtrig when
discussed without reference to a particular base ISA. Krste's proposal
suggests two overlapping uses for RVZ; I suggest using the top-level
namespace for instruction groups and RVZ to indicate support for "loose
instructions", either as a subset of a group or for standardized
instructions that are single-instruction extensions.

In misa, the G and Z bits are used as follows: misa.G is set iff an
implementation supports any extensions other than the baselines for
their categories, while misa.Z is set iff an implementation supports
"loose instructions" not part of an extension. The details of supported
"long-name" extensions shall be in platform configuration data. An
RV32IM_Alrsc implementation would set I, M, and G bits in misa, since
RVA is not fully supported -- only the RVAlrsc subset is implemented.
An RV32IM_Zaamoadd implementation would set I, M, and Z bits in misa,
since RVA is not fully implemented, but the AMOADD instruction is
implemented.



-- Jacob

[kr...@berkeley.edu]

>>>>> On Wed, 15 Nov 2017 12:04:24 -0800 (PST), David Horner <ds2h...@gmail.com> said:
| Is this intended to supersede User Manual section 22.4 Version Numbers?

|| The G ISA subset
|| can be written as “RV64I2p0M2p0A2p0F2p0D2p0”, or more concisely “RV64G2”.
| Or is this proposal orthogonal to it. There is of course some
| overlap/correlation.

Orthogonal to version numbers.

| In either case, will we define G (in RV64G, say) to be = IMAFDSU =
| Za_Zd_Zf_Zi_Zm_Zs_Zu ?

Though by convention we'd write in same order:
Zi_Zm_Za_Zf_Zd_Zs

S implies U, so doesn't need to be explicitly added.

| more questions in context below:

| On 2017-11-15 06:53 AM, krste wrote:
|| | this proposal is trying to ensure that
|| | extensions remain purely additive, so you wouldn't have an RV32IM with
|| | Zmnodiv and platforms that don't provide divide instructions (either
|| | in hardware or trapped+emulated by the runtime) would best be
|| | described as something like RV32I with Zmmulinsts (defining Zmmulinsts
|| | to imply Zmmul, Zmmulh, Zmmulhsu, Zmmulhu). Is that right?
||
|| Right - though maybe use the shorter name Zmul (Zm + ul) to describe
|| that set (so, "RV32I_Zmul" would be a common configuration).
| The convention is definitive to enumerating individual instructions (
| "Z" + category + instruction_name).
| However, as illustrated by Zmul, in general defining grouping of
| instructions is more arbitrary.
| Are we anticipating that the canonical listing will attempt to maintain
| the groups in a strict hierarchy of sub-groups?
| I say attempt, because I expect it will be impractical for the purposes
| mentioned.
| Convenience in providing convenient names for common use cases likely
| will conflict.

Strict hierarchy is probably not desirable. Convenience is important,
and we'll keep a database of instruction names and groupings to avoid
conflicts.

|| But staying compatible with other gcc targets is also important, so I
|| would propose we keep existing "-mno-div" flag.
||
|| It is worth discussing if we want to have negative extensions "Zno---"
|| to simplify compiler command strings.
| I'd suggest ZZ prefix for such negative extensions which will avoid
| namespace collision (N extension in this case).

I fear ZZ is too easily misread, and also, might be better reserved to
extend to further subcategories. ZO or Z0 prefix might be better
choices here.

The philosophy should be that if you advertise support for
instruction, software should not be motivated to code around its
implementation. In this case, the microcoded AMOs should be faster
than any software alternative, or you shouldn't have bothered
implementing them.

| And of course, ZaAMOwithMemorySupport when amo is performed in the
| memory subsystem.
| Perhaps this is best in "platform config string / device tree" rather
| than a instruction set Z qualifier.

| This AMO example illustrates the difficulty in determining "expected
| functionality and performance level" for different use cases.
| Software could well take a different approach in locking if each AMO is
| MicroCoded vs knowing it could use InMemoryAMOAssist.

|| So, a
|| hardware platform should be able to claim to support F and D even if
|| subnormals cause traps.
| Here I would recommend ZZsubnornalsmaytrap be explicitly part of the
| FDQV standard, overridden by a Zfsubnormals, etc .

We have to try and keep things reasonably simple. The full ISA string
will be too long if we include all these details in a description of a
part, and it will be almost impossible to standardize all the possible
implementation subtleties. When tuning at this level, I'd suggest
applications that care should perform autotuning, as mapping from a
full set of microarchitecture parameters for an implementation to the
best software implementation is highly non-linear.

I think we can try and capture standard names for common
implementation choices as you've outlined above, but not require these
are displayed in common use cases, e.g.,

IMAFDC

versus

I_Z0imisaligntrap_MA_Z0amisaligntrap_Z0aAMOemulateLRSC_F_Zfsubnormals_D_Zdsubnormals_C

I'd argue almost all software wouldn't care about the details in the
expanded version. They can be made available to software but not used
even in description of profiles, for example.

Krste

[kr...@berkeley.edu]

>>>>> On Wed, 15 Nov 2017 22:37:22 -0600, Jacob Bachmeyer
>>>>> <jcb6...@gmail.com> said:
[....]

|| Pseudo-instructions that represent a restricted encoding of a given
|| instruction are also named, e.g.,
|| Zirdinstret
|| Zirdcycle
|| Zirdtime
| This could create very long names; would these generally be implied and
| used only to indicate the presence of a few instructions from a larger
| extension?

Yes.

[...]

|| If the Z bit is set, there may be additional standard instructions
|| defined in each category.

| So misa.Z is set to indicate the presence of "loose instructions"?

Yes.

|| The G bit will be used to indicate there are additional instruction categories.

| Do I understand correctly that misa.G indicates the presence of
| "long-name" extensions, while misa.Z indicates individual instructions
| indicated with the "Z" syntax?

G is an escape to indicate there are more categories. Z indicates
there are more instructions than captured in the base single-letter
extensions in misa.

| For discussion, I offer a counter-proposal that all single-letter names
| be changed to categories, with current extensions as "baselines" for
| their categories. In this proposal, Zftrig for trigonometry
| instructions would instead be simply Ftrig and would be implied for an
| implementation that supports Dtrig or Qtrig. Similarly, "A" continues
| to indicate the RVA atomic memory access extension, but "Aamo" and
| "Alrsc" would be distinct names for the AMO and LR/SC subsets. An
| implementation with both subsets simply implements "A". Underscores are
| used canonically to separate multi-character extension names, but since
| extension names are lowercase and categories uppercase, missing
| underscores do not create ambiguity.

Strings have to be case-insensitive.

| Further, the standard way to refer to an extension "X" in the abstract
| would be "RVX"; this is unambiguous with respect to full descriptions
| since those always begin with "RV" and a width. So the floating-point
| trigonometry instructions would be RVFtrig, RVDtrig, and RVQtrig when
| discussed without reference to a particular base ISA. Krste's proposal
| suggests two overlapping uses for RVZ; I suggest using the top-level
| namespace for instruction groups and RVZ to indicate support for "loose
| instructions", either as a subset of a group or for standardized
| instructions that are single-instruction extensions.

| In misa, the G and Z bits are used as follows: misa.G is set iff an
| implementation supports any extensions other than the baselines for
| their categories, while misa.Z is set iff an implementation supports
| "loose instructions" not part of an extension.

This is just really relabeling G as Z, and using Z as a miscellaneous
category. I think we'd want all instructions in some category, and
should work hard to avoid creating misc category.

| The details of supported
| "long-name" extensions shall be in platform configuration data. An
| RV32IM_Alrsc implementation would set I, M, and G bits in misa, since
| RVA is not fully supported -- only the RVAlrsc subset is
| implemented.
| An RV32IM_Zaamoadd implementation would set I, M, and Z bits in misa,
| since RVA is not fully implemented, but the AMOADD instruction is
| implemented.

| -- Jacob

| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5A0D1602.3020501%40gmail.com.

[John Hauser]

Krste wrote:

Though by convention we'd write in same order:
       Zi_Zm_Za_Zf_Zd_Zs

S implies U, so doesn't need to be explicitly added.

Doesn't D also imply F?

    - John Hauser

[Jacob Bachmeyer]

kr...@berkeley.edu wrote:
> On Wed, 15 Nov 2017 22:37:22 -0600, Jacob Bachmeyer <jcb6...@gmail.com> said:
> | For discussion, I offer a counter-proposal that all single-letter names
> | be changed to categories, with current extensions as "baselines" for
> | their categories. In this proposal, Zftrig for trigonometry
> | instructions would instead be simply Ftrig and would be implied for an
> | implementation that supports Dtrig or Qtrig. Similarly, "A" continues
> | to indicate the RVA atomic memory access extension, but "Aamo" and
> | "Alrsc" would be distinct names for the AMO and LR/SC subsets. An
> | implementation with both subsets simply implements "A". Underscores are
> | used canonically to separate multi-character extension names, but since
> | extension names are lowercase and categories uppercase, missing
> | underscores do not create ambiguity.
>
> Strings have to be case-insensitive.
>

In that case, underscores are required, but as all names begin with
single-letter categories, case can then be ignored.

> | Further, the standard way to refer to an extension "X" in the abstract
> | would be "RVX"; this is unambiguous with respect to full descriptions
> | since those always begin with "RV" and a width. So the floating-point
> | trigonometry instructions would be RVFtrig, RVDtrig, and RVQtrig when
> | discussed without reference to a particular base ISA. Krste's proposal
> | suggests two overlapping uses for RVZ; I suggest using the top-level
> | namespace for instruction groups and RVZ to indicate support for "loose
> | instructions", either as a subset of a group or for standardized
> | instructions that are single-instruction extensions.
>
> | In misa, the G and Z bits are used as follows: misa.G is set iff an
> | implementation supports any extensions other than the baselines for
> | their categories, while misa.Z is set iff an implementation supports
> | "loose instructions" not part of an extension.
>
> This is just really relabeling G as Z, and using Z as a miscellaneous
> category. I think we'd want all instructions in some category, and
> should work hard to avoid creating misc category.
>

Not quite, at least as I see it: misa.G would indicate the presence of
"long name" extensions, while misa.Z indicates "loose instructions" that
may be a subset of a named extension. An implementation that supports
AMOSWAP, but no other AMOs, would set misa.Z and include "Zamoswap" in
its configuration data. An implementation with a hypothetical
"FROBNICATE" instruction that stands alone as a standard extension would
set misa.Z and include "Zfrobnicate" in its configuration data.

You are correct that both of these effectively say "examine platform
configuration", but the original proposal uses these bits in a very
similar manner as I understand it. Or did you intend that misa.G
indicate categories beyond the 24 letters of the alphabet less G and Z?
In other words, categories with multi-letter names?

The use of RVZ in my counter-proposal is one of the two uses of Z in the
original proposal: representing individual instructions. I proposed
moving the other use of Z as a catch-all prefix for longer names to
top-level, using the actual category letters directly as prefixes: RVA
is RVA, not both RVA and RVZa as in the original proposal. Similarly, I
propose that the example subsets of RVA be RVAamo and RVAlrsc instead of
RVZaamo and RVZalrsc.

I believe that the original proposal uses RVZ as more of a miscellaneous
category than my counter-proposal does: after all, literally every
extension would have a name in the RVZ space! :-)


-- Jacob