Add disassembler support for all instructions in Zvk extensions:
- Zvbb (bitmanip)
- Zvbc (carryless multiplication)
- Zvkg (GMAC)
- Zvkned (AES)
- Zvknha / Zvknhb (SHA-256, SHA-512)
- Zvksed (SM4)
- Zvksh (SM3)
Macros are used to limit code duplication, following the example
of the base V extension. Because the V extension undefines some
of its macros after their use, there Zvk support does define some
similar macros.
Co-authored-by: Gianluca Guida <gianluca@rivosinc.com>
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Implement the Zvksh sub-extension, "ShangMi Suite: SM3 Hash
Function Instructions":
- vsm3me.vv, message expansion,
- vsm3c.vi, compression rounds.
This also introduces a SM3 specific header for common logic.
Co-authored-by: Raghav Gupta <rgupta@rivosinc.com>
Co-authored-by: Albert Jakieła <aja@semihalf.com>
Co-authored-by: Kornel Dulęba <mindal@semihalf.com>
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Implement the instructions part of the Zvknha and Zvknhb
sub-extensions:
- vsha2ms.vv, message schedule
- vsha2ch.vv / vsha2cl.vv, compression rounds
A header files for common macros is added.
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Implement the proposed instruction in Zvkg, vghmac.vv,
Vector Carryless Multiply Accumulate over GHASH Galois-Field.
The instruction performs one step of GHASH routine as described
in "NIST Special Publication 800-38D" a.k.a the AES-GCM specification.
The logic was written to closely track the pseudo-code
in the Zvk specification.
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Co-authored-by: Kornel Duleba <mindal@semihalf.com>
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Implement the proposed instructions in Zvbb:
- vandn.{vv,vx}, vector bitwise and-not
- vbrev.v, vector bit reverse in element
- vbrev8.v, vector bit reverse in bytes
- vrev8.v, vector byte reverse
- vctz.v, vector count trailing zeros
- vclz.v, vector count leading zeros
- vcpop.v, vector population count
- vrol.{vv,vx}, vector rotate left
- vror.{vi,vv,vx}, vector rotate right
- vwsll.{vi,vv,vx} vector widening shift left logical
A new instruction field, 'zimm6', is introduced, encoded
in bits [15, 19] and [26].. It is used by "vror.vi" to encode
a shift immediate in [0, 63].
Co-authored-by: Raghav Gupta <rgupta@rivosinc.com>
Co-authored-by: Stanislaw Kardach <kda@semihalf.com>
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Introduce types and macros useful across multiple Zvk sub-extensions,
including Zvbb and Zvbc. Those will be used by upcoming
per-sub-extension commits.
In particular we introduce "Element Group" types and loop macros handling
those element groups. The concept of element group is described in
<https://github.com/riscv/riscv-crypto/blob/master/doc/vector/riscv-crypto-vector-element-groups.adoc>.
Note that the element group access method is not implemented
for WORDS_BIGENDIAN setup. As such, isa_parser.cc is modified to emit
an error when WORDS_BIGENDIAN is defined and extensions using element
groups are enabled.
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
Zvk is the short name for the Vector Cryptography Instruction
Set Extension Specification being defined at
<https://github.com/riscv/riscv-crypto/tree/master/doc/vector>.
This commit adds support for parsing/enabling the Zvk extensions
(Zvbb, Zvbc, Zvkg, Zvkned, Zvknha, Zvknhb, Zvksed, Zvksh, Zvkt)
and the combo extensions (Zvkn, Zvknc, Zvkng, Zvks, Zvksc, Zvksg).
This is an early commit in a series implementing Zvk. No instructions
are actually defined here, only infastructure that will
support the coming extensions.
The encodings for Zvk instructions have some conflicts with Zpn
encodings. This commit marks those Zpn instructions as overlapping,
and adds checks to error out if conflicting extensions are enabled.
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
The previous order lacks any obvious logic. Alphabetical order,
while making it difficult to create interesting groupings,
makes it easy to find which extensions are compiled in.
Signed-off-by: Eric Gouriou <ego@rivosinc.com>
The spec says "The PMP access control bits shall be the same for all
physical addresses in the cache block [... else] the behavior of a CBO
instruction is UNSPECIFIED."
Thus, we only need to check the byte rs1 points to
(instead of the entire cache block).
This change was made ages ago in the spec.
I did not actually test that the new privilege checks in ebreak and
c.ebreak are correct, but all the existing debug tests still pass.
Eric Gouriou
Andrew Waterman
Philipp Tomsich
Gianluca Guida
Jerry Zhao
YenHaoChen
demin.han
Weiwei Li
Tim Newsome