ISA Extensions (decoding opcodes)

Michael Clark

unread,

Mar 12, 2016, 2:28:31 AM3/12/16

to RISC-V ISA Specification Discussion

Hi All,

Sharing DRAFT notes on instruction classification sourced from the various RISC-V specifications; provoked by a polymorphic software decoder for RISC-V. I mentioned earlier about adding metadata to opcodes which I need to complete auto generation of statically parameterizable optimised RISC-V decoders (nearly complete). This list below was created during the process as I needed a complete list to annotate opcodes. I have also added ‘hypothetical’ ISA subsets and a new bundle classification. I thought sharing notes might be useful...

~mc

Single Letter Extension Mnemonics (returned by mcpuid)

I - Base Integer Instruction Set
M - Standard Extension for Integer Multiplication and Division
A - Standard Extension for Atomic Instructions
F - Standard Extension for Single-Precision Floating-Point
D - Standard Extension for Double-Precision Floating-Point
Q - Standard Extension for Quad-Precision Floating-Point
L - Standard Extension for Decimal Floating-Point (TBD)
C - Standard Extension for Compressed Instructions
B - Standard Extension for Bit Manipulation (TBD)
T - Standard Extension for Transactional Memory (TBD)
P - Standard Extension for Packed-SIMD Instructions (TBD)
S - Hypothetical Extension for Supervisor-level Instructions (privileged-spec)
H - Hypothetical Extension for Hypervisor-level Instructions (privileged-spec TBD)
V - Hwacha Extension for Variable-length-vector Instructions (UCB/EECS-2015-262)
E - Reduced Register Set Indicator (16 registers)
G - Bundle Indicator IMAFDCS
X - Hypothetical Bundle Indicator IMAFDQLCBTPSHV

Note: Added hypothetical S, H, V extensions and X bundle
Note: Consider classifying system instructions ’S’ instead of ‘I'. Implementation could use illegal instruction exception and a hypervisor could potentially mask instructions based on an extension bit that mirrors extension bits in mcpuid.

Bundles

* RV32E = RV32I with 16 registers
* RV32G = RV32IMAFDCS
* RV64G = RV64IMAFDCS
* RV128G = RV128IMAFDCS
* RV128X = RV128IMAFDQLCBTPSHV

Note: Added S to RV32G, RV64G and RV128G

Constraints

* One of I or E are mandatory
* E is only available on RV32 ?
* D depends on F
* Q depends on D
* H depends on S
* M, A, L, C, B, T, P, S, V are independent

signature.asc

Tommy Thorn

unread,

Mar 12, 2016, 1:20:14 PM3/12/16

to Michael Clark, RISC-V ISA Specification Discussion

D doesn’t depend on F.

> --
> 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/A84A7F3D-694F-4162-839E-B64E32F889AE%40mac.com.

Christopher Celio

unread,

Mar 12, 2016, 1:34:25 PM3/12/16

to Michael Clark, RISC-V ISA Specification Discussion

Chapter 11 of the user manual covers the naming of extensions, and contradicts some of the proposed mnemonics.

X is already used to describe non-standard extensions.

Hwacha is covered by Xhwacha, it being a non-standard extension.

V is a proposed fixed-length vector extension (a workshop talk has been given on it). Hwacha is NOT the vector extension proposal, but a purely research-driven extension for exploring new architectural/micro-architectural ideas.

G is IMAFD. It does not include C or S.

* E is only available on RV32 ?

Yes, E is not available in 64-bit.

-Chris

Michael Clark

unread,

Mar 12, 2016, 3:15:31 PM3/12/16

to RISC-V ISA Specification Discussion

? - Standard Extension for Cryptography Instructions

* SHA2

* SHA3

* AES

* 128-bit Carryless Multiply for GCM GF(2^128)

* BLAKE2

* ChaCha20

* Poly1305

There is a lot of interest in BLAKE2 (*1) and ChaCha20-Poly1305 (*2) in the Crypto Forum Research Group (CFRG) and the IETF TLS Working Group. Google and CloudFlare have recently implemented ChaCha20-Poly1305 in TLS. BLAKE2 is also gaining a lot of attention as it is faster than SHA-3 and has equivalent security. A little bit of research shows implementations in FPGA. BLAKE2 had a design goal of efficient implementation in FPGA and ASIC.

There is not much point implementing SHA1. Intel released their hardware SHA1 implementation on the cusp of its deprecation.

[1] https://blake2.net/

[2] https://tools.ietf.org/html/rfc7539

Michael Clark

unread,

Mar 12, 2016, 5:09:05 PM3/12/16

to Christopher Celio, RISC-V ISA Specification Discussion

> On 13 Mar 2016, at 7:34 AM, Christopher Celio <ce...@eecs.berkeley.edu> wrote:
>
> Chapter 11 of the user manual covers the naming of extensions, and contradicts some of the proposed mnemonics.
>
> X is already used to describe non-standard extensions.
>
> Hwacha is covered by Xhwacha, it being a non-standard extension.
>
> V is a proposed fixed-length vector extension (a workshop talk has been given on it). Hwacha is NOT the vector extension proposal, but a purely research-driven extension for exploring new architectural/micro-architectural ideas.
>
> G is IMAFD. It does not include C or S.
>
>> * E is only available on RV32 ?
>
> Yes, E is not available in 64-bit.

Thanks. This helps.

I think based on this that I can label system instructions S?

This is not clear in the RISC-V ISA manual v2.0. “2.8 System Instructions” does not have a “S” prefix as per the other sections and the system instructions are in included in the “I” section in Table 8.2: Instruction listing for RISC-V, "RV32I Base Instruction Set", however riscv-opcodes/opcodes has them commented as “System”.

I was not aware of V.

Thanks and Regards,
Michael

Colin Schmidt

unread,

Mar 12, 2016, 10:22:59 PM3/12/16

to Michael Clark, Christopher Celio, RISC-V ISA Specification Discussion

I wanted to clarify what Chris said about the standard V extension and Hwacha.

Hwacha as Chris said is a purely research design and will not be the standard V extension. You can find several tech reports[1,2,3] on it and we plan to open source its RTL, toolchain, and compiler soon. This is what is pointed to by the ucb-bar/esp-* repositories (not yet public).

The standard V extension (talk slides [4]) is much closer to a traditional vector ISA, with the addition of some modern features. This means its instructions operate on a programmatically defined vector length (not fixed-length in the instruction encoding), but the instructions themselves will be fixed at 32-bits. Please see the above slides for more details on how this programming model works.

Thanks,

Colin

[1] https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.html

[2] https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.html

[3] https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-264.html

[4] http://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf

--
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/ADB8660B-D684-4673-A478-BB375D914D5E%40mac.com.

Ray VanDeWalker

unread,

Mar 14, 2016, 6:45:19 PM3/14/16

to RISC-V ISA Specification Discussion

My reading of the discussion of the V instruction set at http://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf

is that the authors hoped (back in June 29, 2015) to subsume and abort a P-type vector ISA with clever, minimal implementations of the V-type ISA.

If this is working out (my once-over didn’t see a hole), the P stuff is pretty hypothetical.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/58E4D785-FA85-4700-81C2-B959613B0C6C%40eecs.berkeley.edu.

Michael Clark

unread,

Mar 18, 2016, 5:55:16 PM3/18/16

to Tommy Thorn, RISC-V ISA Specification Discussion

Dear Tommy, All,

The statement "D doesn’t depend on F” doesn’t perfectly agree with current wording in The RISC-V Instruction Set Manual Volume I: User-Level ISA Version 2.0, Table 8.2: Instruction listing for RISC-V.

The floating point status and control register instructions are defined only for RV32F and RV64F and are in the section “RV32F Standard Extension” and by proxy "RV64F Standard Extension (in addition to RV32F)"

frcsr
frrm
frflags
fscsr
fsrm
fsflags
fsrmi
fsflagsi

The way the specification is “currently” worded, I can see these dependencies:

* D depends on F

* Q depends on D (or F)

Can someone please clarify?

If the floating point instruction extensions are indeed independent then we should perhaps label them differently so that parse-opcodes can produce LaTeX with a separate section:

"RV32F and RV32D Common Floating-Point Instructions"

They are an odd bunch as they sit within the S encoding space but are required for F, D and Q.

~mc

signature.asc

Andrew Waterman

unread,

Mar 18, 2016, 10:28:36 PM3/18/16

to Michael Clark, Tommy Thorn, RISC-V ISA Specification Discussion

As written in the spec, D does depend on F. It's of course possible
to omit instructions like FADD.S, either as a non-standard variant, or
relying on M-mode emulation code to provide them.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/D84A3F85-F2D6-4F42-9A33-1D528888FB57%40mac.com.

Reply all

Reply to author

Forward