In general, the strategy has been that the disassembler enables a
maximal set of non-conflicting extensions, thereby doing the right thing
for the largest number of users.
This change lets me test OpenOCD's behavior when harts become available.
It only affects how things look to the debugger. Harts that are
"unavailable" still execute code as usual.
Control is implemented through the 2 LSBs of the DMCUSTOM register in
the Debug Module.
Plugins should now implement and register a device_factory_t to
configure how that device should be parsed from a FDT, and an optional
default DTS string.
This drops support for command-line flag-based device configuration
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>