* Add 'spmp' in isa string parsing for SPMP extension
* Add PMP_Entry CSRs of spmp
* Implement SPMP matching logic
* Update implementation to spec rc5 version
Keep extension_info_t focused on extension enable/imply data
by moving XLEN policy checks back into explicit post-parse validation.
This keeps the table structure simpler while preserving the existing
checks for Zcf, Zclsd, Zilsd, and svukte after implication and
combination rules have settled.
Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
Replace the long hard-coded extension dispatch chain in isa_parser.cc with
table-driven extension metadata. The table now records the extension name,
the extension bits it enables, direct implied extensions, and simple XLEN
requirements. This makes the parser behavior closer to LLVM, where
extension parsing and implication are represented as data rather than
as a large sequence of adhoc conditionals.
Move MISA single-letter extensions into the same table as multi-letter
extensions. The parser now expands `g` to `imafd`, validates that the base
extension is `i`, `e`, or `g`, and then lets the normal single-letter parsing
loop consume the base extension through the table. This also centralizes
common MISA implications such as `a -> zaamo,zalrsc`, `b -> zba,zbb,zbs`,
`d -> f`, `q -> d,f`, `c -> zca`, and `v -> zve64d,zvl128b`.
Model the Zve implication chain explicitly in the extension table
zve32f -> zve32x, f
zve32x -> zicsr, zvl32b
zve64d -> zve64f, d
zve64f -> zve32f, zve64x
zve64x -> zve32x, zvl64b
v -> zve64d, zvl128b
Keep the Spike-specific Zve state updates out of the table by deriving
VLEN, ELEN, zvf, and zvd from the Zve extension name in a small helper.
Add a separate combine pass for reverse combination rules that reconstruct
combined extension bits from their component bits. This keeps combine logic
separate from forward implication while preserving existing Spike behavior:
zaamo + zalrsc -> A
zba + zbb + zbs -> B
C + D -> Zcd
Zicfiss + Zca -> Zcmop
Retain explicit Spike-specific post-parse checks and derived state where they
remain clearer than table entries, including RV32-only `C/Zce + F -> Zcf`,
`Zfbfmin/Zfhmin -> EXT_INTERNAL_ZFH_MOVE`, incompatibility checks, privilege
mode handling, and VLEN limit validation.
Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
We should allow ISA strings like rv64gc_zve32f. Per the spec, the
various Zve extensions imply a minimum VLEN, so rv64gc_zve32f
is unambiguously equivalent to rv64gc_zve32f_zvl32b. Similarly,
rv64gc_zve64x, rv64gc_zve64x_zvl64b, and rv64gc_zve64x_zvl32b are
all unambiguously equivalent.
* Enable EXT_INTERNAL_ZFH_MOVE when either Zfbfmin or Zfhmin is enabled
* Change Zvfbfmin to require Zve32f instead of V extension.
* Add proper dependency chain for Zvfbfwma requiring both Zvfbfmin and Zfbfmin.
Binno
Chih-Min Chao
Zhibo Hong
Jerry Zhang Jian
Andrew Waterman
Michelle Wu
mslijepc
Alexander Romanov
Alexander Romanov
Andrew Young
Aliaksei Chapyzhenka
Nadime Barhoumi
Nado15
Hao
YenHaoChen
Muhammad Moiz Hussain
Mingzhu Yan
Mahmoud Abumandour