riscv
/
riscv-isa-sim
mirror of https://github.com/riscv-software-src/riscv-isa-sim.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Spike, a RISC-V ISA Simulator
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4066 Commits
53 Branches
3 Tags
19 MiB
Tree: bf330d352f
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bf330d352f'
${ noResults }
riscv-isa-sim/disasm/isa_parser.cc

456 lines
14 KiB
Raw Normal View History

Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
#include "isa_parser.h"
isa_parser: don't append one char at a time in strtolower This avoids potential re-alloations as it allocates the result string upfront.
1 year ago
#include <cstring>
Refactor ISA parser extension handling 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>
2 weeks ago
#include <initializer_list>
Fix: Add missing <stdexcept> header for std::logic_error - Included <stdexcept> in isa_parser.cc to resolve compilation error due to missing type 'std::logic_error'. Signed-off-by: Rafael Sene <rafael@riscv.org>
2 years ago
#include <stdexcept>
Refactor ISA parser extension handling 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>
2 weeks ago
#include <vector>
namespace {
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
static std::string strtolower(const char* str)
{
isa_parser: don't append one char at a time in strtolower This avoids potential re-alloations as it allocates the result string upfront.
1 year ago
std::string res(str);
for (char &c : res)
c = std::tolower(c);
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
return res;
}
Validate Zvl ISA string correctly See #1810 for explanation of how this can go wrong. Resolves #1810
2 years ago
static unsigned long safe_stoul(const std::string& s)
{
int old_errno = errno;
errno = 0;
char* endp;
unsigned long ret = strtoul(s.c_str(), &endp, 10);
int new_errno = errno;
errno = old_errno;
if (endp == s.c_str() || *endp)
throw std::invalid_argument("stoul");
if (new_errno)
throw std::out_of_range("stoul");
return ret;
}
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
static void bad_option_string(const char *option, const char *value,
const char *msg)
{
fprintf(stderr, "error: bad %s option '%s'. %s\n", option, value, msg);
abort();
}
static void bad_isa_string(const char* isa, const char* msg)
{
bad_option_string("--isa", isa, msg);
}
static void bad_priv_string(const char* priv)
{
fprintf(stderr, "error: bad --priv option %s\n", priv);
abort();
}
Refactor ISA parser extension handling 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>
2 weeks ago
struct extension_info_t {
const char* name;
std::vector<unsigned> enables;
std::vector<const char*> implies;
fixup! Refactor ISA parser extension handling Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
2 weeks ago
// `enables` sets extension_table bits directly
// `implies` recursively parses and applies other named extensions
Refactor ISA parser extension handling 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>
2 weeks ago
extension_info_t(const char* name,
std::initializer_list<unsigned> enables = {},
fixup! Refactor ISA parser extension handling 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>
2 weeks ago
std::initializer_list<const char*> implies = {})
: name(name), enables(enables), implies(implies) {}
Refactor ISA parser extension handling 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>
2 weeks ago
};
fixup! Refactor ISA parser extension handling Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
2 weeks ago
// if every extension in components is set, also set the enable
Refactor ISA parser extension handling 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>
2 weeks ago
struct extension_combination_t {
unsigned enable;
std::vector<unsigned> components;
extension_combination_t(unsigned enable,
std::initializer_list<unsigned> components = {})
: enable(enable), components(components) {}
};
fixup! Refactor ISA parser extension handling Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
2 weeks ago
// Entries without enables set no extension_table bits directly. This is either
// because no dedicated EXT_* bit exists for them (their full effect is expressed
// through their implies chain), or because their behavior is always present in
// Spike, is currently unmodeled, or is handled by later parser checks.
Refactor ISA parser extension handling 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>
2 weeks ago
static const extension_info_t extension_infos[] = {
{"i", {'I'}},
{"e", {'E'}},
{"m", {'M'}},
{"a", {'A'}, {"zaamo", "zalrsc"}},
{"f", {'F'}},
{"d", {'D', 'F'}},
{"q", {'Q', 'D', 'F'}},
{"c", {'C'}, {"zca"}},
{"b", {'B'}, {"zba", "zbb", "zbs"}},
{"p", {'P'}},
{"v", {'V'}, {"zve64d", "zvl128b"}},
{"h", {'H'}},
{"zfh", {EXT_ZFH}, {"zfhmin"}},
{"zfhmin", {'F', EXT_ZFHMIN}},
{"zvfh", {EXT_ZVFH}, {"zvfhmin", "zfhmin"}},
{"zvfhmin", {EXT_ZVFHMIN}, {"zve32f"}},
{"zvfbfa", {EXT_ZVFBFA}, {"zve32f", "zfbfmin"}},
{"zvfofp4min", {EXT_ZVFOFP4MIN}, {"zve32f"}},
{"zvfofp8min", {EXT_ZVFOFP8MIN}, {"zve32f"}},
{"zicsr"},
{"zifencei"},
{"zihintpause"},
{"zihintntl"},
{"ziccid", {EXT_ZICCID}},
{"ziccif"},
{"zve32x", {}, {"zicsr", "zvl32b"}},
{"zve32f", {}, {"zve32x", "f"}},
{"zve64x", {}, {"zve32x", "zvl64b"}},
{"zve64f", {}, {"zve32f", "zve64x"}},
{"zve64d", {}, {"zve64f", "d"}},
{"zaamo", {EXT_ZAAMO}},
{"zalrsc", {EXT_ZALRSC}},
{"zacas", {EXT_ZACAS, EXT_ZAAMO}},
{"zabha", {EXT_ZABHA, EXT_ZAAMO}},
{"zawrs", {EXT_ZAWRS, EXT_ZALRSC}},
Add support for Za64rs and Za128rs extensions.
2 months ago
{"za64rs", {EXT_ZA64RS}, {"zalrsc"}},
{"za128rs", {EXT_ZA128RS}, {"zalrsc"}},
Refactor ISA parser extension handling 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>
2 weeks ago
{"zama16b", {EXT_ZAMA16B}},
{"zmmul", {EXT_ZMMUL}},
{"zba", {EXT_ZBA}},
{"zbb", {EXT_ZBB}},
{"zbc", {EXT_ZBC}},
{"zbs", {EXT_ZBS}},
{"zbkb", {EXT_ZBKB}},
{"zbkc", {EXT_ZBKC}},
{"zbkx", {EXT_ZBKX}},
{"zdinx", {EXT_ZFINX, EXT_ZDINX}},
{"zfbfmin", {'F', EXT_ZFBFMIN}},
{"zfinx", {EXT_ZFINX}},
{"zhinx", {EXT_ZFINX, EXT_ZHINX, EXT_ZHINXMIN}},
{"zhinxmin", {EXT_ZFINX, EXT_ZHINXMIN}},
{"zce", {EXT_ZCE}, {"zcb", "zcmp", "zcmt"}},
{"zca", {EXT_ZCA}},
fixup! Refactor ISA parser extension handling 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>
2 weeks ago
{"zcf", {'F', EXT_ZCF}, {"zca"}},
Refactor ISA parser extension handling 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>
2 weeks ago
{"zcb", {EXT_ZCB}, {"zca"}},
{"zcd", {EXT_ZCD, 'F', 'D'}, {"zca"}},
{"zcmp", {EXT_ZCMP}, {"zca"}},
{"zcmt", {EXT_ZCMT}, {"zca", "zicsr"}},
{"zibi", {EXT_ZIBI}},
{"zk", {EXT_ZBKB, EXT_ZBKC, EXT_ZBKX, EXT_ZKND, EXT_ZKNE, EXT_ZKNH, EXT_ZKR}},
{"zkn", {EXT_ZBKB, EXT_ZBKC, EXT_ZBKX, EXT_ZKND, EXT_ZKNE, EXT_ZKNH}},
{"zknd", {EXT_ZKND}},
{"zkne", {EXT_ZKNE}},
{"zknh", {EXT_ZKNH}},
{"zks", {EXT_ZBKB, EXT_ZBKC, EXT_ZBKX, EXT_ZKSED, EXT_ZKSH}},
{"zksed", {EXT_ZKSED}},
{"zksh", {EXT_ZKSH}},
{"zkr", {EXT_ZKR}},
{"zkt"},
{"smepmp", {EXT_SMEPMP}},
{"smstateen", {EXT_SMSTATEEN}},
{"smpmpmt", {EXT_SMPMPMT}},
{"smrnmi", {EXT_SMRNMI}},
{"sscofpmf", {EXT_SSCOFPMF}},
{"svadu", {EXT_SVADU}},
{"svade", {EXT_SVADE}},
{"svnapot", {EXT_SVNAPOT}},
{"svpbmt", {EXT_SVPBMT}},
{"svinval", {EXT_SVINVAL}},
fixup! Refactor ISA parser extension handling 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>
2 weeks ago
{"svukte", {EXT_SVUKTE}},
Refactor ISA parser extension handling 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>
2 weeks ago
{"zfa", {EXT_ZFA}},
{"zicbom", {EXT_ZICBOM}},
{"zicboz", {EXT_ZICBOZ}},
{"zicbop"},
{"zicclsm", {EXT_ZICCLSM}},
{"zicntr", {EXT_ZICNTR}},
{"zicond", {EXT_ZICOND}},
{"zihpm", {EXT_ZIHPM}},
fixup! Refactor ISA parser extension handling 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>
2 weeks ago
{"zilsd", {EXT_ZILSD}},
{"zclsd", {EXT_ZCLSD}, {"zilsd", "zca"}},
Refactor ISA parser extension handling 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>
2 weeks ago
{"zvabd", {EXT_ZVABD}},
{"zvkb", {EXT_ZVKB}},
{"zvbb", {EXT_ZVKB, EXT_ZVBB}},
{"zvbc", {EXT_ZVBC}},
{"zvfbfmin", {EXT_ZVFBFMIN}, {"zve32f"}},
{"zvfbfwma", {EXT_ZVFBFWMA}, {"zfbfmin", "zvfbfmin"}},
{"zvkg", {EXT_ZVKG}},
{"zvkn", {EXT_ZVKB, EXT_ZVKNED, EXT_ZVKNHB}},
{"zvknc", {EXT_ZVKB, EXT_ZVBC, EXT_ZVKNED, EXT_ZVKNHB}},
{"zvkng", {EXT_ZVKB, EXT_ZVKG, EXT_ZVKNED, EXT_ZVKNHB}},
{"zvkned", {EXT_ZVKNED}},
{"zvknha", {EXT_ZVKNHA}},
{"zvknhb", {EXT_ZVKNHB}},
{"zvks", {EXT_ZVKB, EXT_ZVKSED, EXT_ZVKSH}},
{"zvksc", {EXT_ZVKB, EXT_ZVBC, EXT_ZVKSED, EXT_ZVKSH}},
{"zvksg", {EXT_ZVKB, EXT_ZVKG, EXT_ZVKSED, EXT_ZVKSH}},
{"zvksed", {EXT_ZVKSED}},
{"zvksh", {EXT_ZVKSH}},
{"zvqdotq", {EXT_ZVQDOTQ}},
{"zvqbdot8i", {EXT_ZVQBDOT8I}},
{"zvqbdot16i", {EXT_ZVQBDOT16I}},
{"zvfqbdot8f", {EXT_ZVFQBDOT8F}},
{"zvfwbdot16bf", {EXT_ZVFWBDOT16BF}},
{"zvfbdot32f", {EXT_ZVFBDOT32F}},
{"zvqldot8i", {EXT_ZVQLDOT8I}},
{"zvqldot16i", {EXT_ZVQLDOT16I}},
{"zvfqldot8f", {EXT_ZVFQLDOT8F}},
{"zvfwldot16bf", {EXT_ZVFWLDOT16BF}},
{"zvkt"},
{"zvzip", {EXT_ZVZIP}},
{"sstc", {EXT_SSTC}},
{"smcsrind", {EXT_SMCSRIND}},
{"sscsrind", {EXT_SSCSRIND}},
{"smcntrpmf", {EXT_SMCNTRPMF}},
{"smcdeleg", {EXT_SMCDELEG}},
{"ssccfg", {EXT_SSCCFG}},
{"zimop", {EXT_ZIMOP}},
{"zcmop", {EXT_ZCMOP}, {"zca"}},
{"zalasr", {EXT_ZALASR}},
{"ssqosid", {EXT_SSQOSID}},
{"zicfilp", {EXT_ZICFILP}},
{"zicfiss", {EXT_ZICFISS}, {"zaamo", "zimop"}},
{"smmpm", {EXT_SMMPM}},
{"smnpm", {EXT_SMNPM}},
{"ssnpm", {EXT_SSNPM}},
{"ssdbltrp", {EXT_SSDBLTRP}},
{"smdbltrp", {EXT_SMDBLTRP}},
{"smaia", {EXT_SMAIA, EXT_SSAIA, EXT_SMCSRIND, EXT_SSCSRIND}},
{"ssaia", {EXT_SSAIA, EXT_SSCSRIND}},
{"svvptc"},
};
static const extension_combination_t extension_combinations[] = {
{'A', {EXT_ZAAMO, EXT_ZALRSC}},
{'B', {EXT_ZBA, EXT_ZBB, EXT_ZBS}},
{EXT_ZCD, {'C', 'D'}},
{EXT_ZCMOP, {EXT_ZICFISS, EXT_ZCA}},
};
static const extension_info_t* find_extension_info(const std::string& ext)
{
for (const auto& info : extension_infos)
if (ext == info.name)
return &info;
return nullptr;
}
static void apply_extension_combinations(std::bitset<NUM_ISA_EXTENSIONS>& extension_table)
{
for (const auto& combination : extension_combinations) {
if (combination.components.empty())
continue;
bool has_all_components = true;
for (const auto component : combination.components) {
has_all_components &= extension_table[component];
}
if (has_all_components)
extension_table[combination.enable] = true;
}
}
} // namespace
void isa_parser_t::apply_zve_properties(const std::string& ext_str, const char* str)
{
if (ext_str.size() != 6)
bad_isa_string(str, ("Invalid Zve string: " + ext_str).c_str());
reg_t new_elen;
try {
new_elen = safe_stoul(ext_str.substr(3, ext_str.size() - 4));
} catch (std::logic_error& e) {
new_elen = 0;
}
switch (ext_str.back()) {
case 'd':
zvd |= true;
[[fallthrough]];
case 'f':
zvf |= true;
break;
case 'x':
break;
default:
new_elen = 0;
}
if (new_elen != 32 && new_elen != 64)
bad_isa_string(str, ("Invalid Zve string: " + ext_str).c_str());
elen = std::max(elen, new_elen);
vlen = std::max(vlen, new_elen);
}
Factor out add_extension method
4 months ago
void isa_parser_t::add_extension(const std::string& ext_str, const char* str)
{
Refactor ISA parser extension handling 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>
2 weeks ago
if (const auto* info = find_extension_info(ext_str)) {
for (const auto ext : info->enables) {
extension_table[ext] = true;
}
for (const auto implied : info->implies) {
add_extension(implied, str);
}
if (ext_str.substr(0, 3) == "zve")
apply_zve_properties(ext_str, str);
Factor out add_extension method
4 months ago
} else if (ext_str.substr(0, 3) == "zvl") {
reg_t new_vlen;
try {
new_vlen = safe_stoul(ext_str.substr(3, ext_str.size() - 4));
} catch (std::logic_error& e) {
new_vlen = 0;
}
if ((new_vlen & (new_vlen - 1)) != 0 || new_vlen < 32 || ext_str.back() != 'b')
bad_isa_string(str, ("Invalid Zvl string: " + ext_str).c_str());
vlen = std::max(vlen, new_vlen);
Refactor ISA parser extension handling 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>
2 weeks ago
} else if (!ext_str.empty() && ext_str[0] == 'x') {
Factor out add_extension method
4 months ago
extension_table['X'] = true;
if (ext_str.size() == 1) {
bad_isa_string(str, "single 'X' is not a proper name");
} else if (ext_str != "xdummy") {
extensions.insert(ext_str.substr(1));
}
} else {
bad_isa_string(str, ("unsupported extension: " + ext_str).c_str());
}
}
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
isa_parser_t::isa_parser_t(const char* str, const char *priv)
{
isa_string = strtolower(str);
Fix ordering of B single-letter extension The canonical order is IMAFDQLCBKJTPVH Signed-off-by: Jerry Zhao <jerryz123@berkeley.edu>
2 years ago
const char* all_subsets = "mafdqcbpvh";
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
if (isa_string.compare(0, 4, "rv32") == 0)
Keep max_isa and extension_table in sync in exactly one place This fixes a bug where --isa=rv64imafdc would fail to set extension_table['F'] because of the ad hoc manner in which we were synchronizing max_isa and extension_table.
3 years ago
max_xlen = 32;
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
else if (isa_string.compare(0, 4, "rv64") == 0)
max_xlen = 64;
else
bad_isa_string(str, "ISA strings must begin with RV32 or RV64");
Add isa_parser parsing for zvl/zve
2 years ago
vlen = 0;
elen = 0;
zvf = false;
zvd = false;
Refactor ISA parser extension handling 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>
2 weeks ago
if (isa_string[4] == 'g') {
// G = IMAFD_Zicsr_Zifencei, but Spike includes the latter two
// unconditionally, so they need not be explicitly added here.
isa_string = isa_string.substr(0, 4) + "imafd" + isa_string.substr(5);
} else if (isa_string[4] != 'i' && isa_string[4] != 'e') {
bad_isa_string(str, ("'" + isa_string.substr(0, 4) + "' must be followed by I, E, or G").c_str());
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
}
Refactor ISA parser extension handling 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>
2 weeks ago
add_extension(std::string(1, isa_string[4]), str);
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
const char* isa_str = isa_string.c_str();
auto p = isa_str, subset = all_subsets;
for (p += 5; islower(*p) && !strchr("zsx", *p); ++p) {
while (*subset && (*p != *subset))
++subset;
if (!*subset) {
if (strchr(all_subsets, *p))
bad_isa_string(str, ("Extension '" + std::string(1, *p) + "' appears too late in ISA string").c_str());
else
bad_isa_string(str, ("Unsupported extension '" + std::string(1, *p) + "'").c_str());
}
Refactor ISA parser extension handling 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>
2 weeks ago
add_extension(std::string(1, *p), str);
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
while (isdigit(*(p + 1))) {
++p; // skip major version, point, and minor version if presented
if (*(p + 1) == 'p') ++p;
}
p += *(p + 1) == '_'; // underscores may be used to improve readability
}
while (islower(*p) || (*p == '_')) {
p += *p == '_'; // first underscore is optional
auto end = p;
do ++end; while (*end && *end != '_');
auto ext_str = std::string(p, end);
p = end;
Factor out add_extension method
4 months ago
add_extension(ext_str, str);
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
}
if (*p) {
bad_isa_string(str, ("can't parse: " + std::string(p)).c_str());
}
Refactor ISA parser extension handling 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>
2 weeks ago
apply_extension_combinations(extension_table);
Add Zaamo and Zalrsc extensions
2 years ago
Refactor ISA parser extension handling 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>
2 weeks ago
if (extension_table[EXT_ZFBFMIN] || extension_table[EXT_ZFHMIN]) {
extension_table[EXT_INTERNAL_ZFH_MOVE] = true;
add support for flags for Zc* extensions
4 years ago
}
Clean up handling of Zcf
4 months ago
if (extension_table['C'] || extension_table[EXT_ZCE]) {
if (extension_table['F'] && max_xlen == 32)
extension_table[EXT_ZCF] = true;
}
fixup! Refactor ISA parser extension handling 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>
2 weeks ago
if (extension_table[EXT_ZCF] && max_xlen != 32) {
bad_isa_string(str, "'Zcf' requires RV32");
}
if (extension_table[EXT_ZCLSD] && max_xlen != 32) {
bad_isa_string(str, "'Zclsd' requires RV32");
}
if (extension_table[EXT_ZILSD] && max_xlen != 32) {
bad_isa_string(str, "'Zilsd' requires RV32");
}
if (extension_table[EXT_SVUKTE] && max_xlen != 64) {
bad_isa_string(str, "'svukte' requires RV64");
}
Have Zclsd imply extensions rather than erroring if not present
4 months ago
if (extension_table[EXT_ZCLSD] && extension_table[EXT_ZCF]) {
bad_isa_string(str, "'Zclsd' extension conflicts with 'Zcf' extensions");
}
Keep max_isa and extension_table in sync in exactly one place This fixes a bug where --isa=rv64imafdc would fail to set extension_table['F'] because of the ad hoc manner in which we were synchronizing max_isa and extension_table.
3 years ago
if (extension_table[EXT_ZFINX] && extension_table['F']) {
Improve Zfinx error message
4 years ago
bad_isa_string(str, ("Zfinx/Zdinx/Zhinx{min} extensions conflict with 'F/D/Q/Zfh{min}' extensions"));
Add flags for Zfinx/Zdinx/Zhinx{min} Hardwire mstatus_fs to zero when enable ZFinx
5 years ago
}
add support for flags for Zc* extensions
4 years ago
if ((extension_table[EXT_ZCMP] || extension_table[EXT_ZCMT]) && extension_table[EXT_ZCD]) {
Zvk: extensions parsing 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>
3 years ago
bad_isa_string(str, "Zcmp' and 'Zcmt' extensions are incompatible with 'Zcd' extension");
add support for flags for Zc* extensions
4 years ago
}
Zvk: Infrastructure for Zvk extensions, element group handling 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>
3 years ago
#ifdef WORDS_BIGENDIAN
// Access to the vector registers as element groups is unimplemented on big-endian setups.
if (extension_table[EXT_ZVKG] || extension_table[EXT_ZVKNHA] || extension_table[EXT_ZVKNHB] ||
extension_table[EXT_ZVKSED] || extension_table[EXT_ZVKSH]) {
bad_isa_string(str,
"'Zvkg', 'Zvkned', 'Zvknha', 'Zvknhb', 'Zvksed', and 'Zvksh' "
"extensions are incompatible with WORDS_BIGENDIAN setups.");
}
#endif
Add Zvl/Zve validation to isa_parser
2 years ago
Restrict spike to vlen <= 4096
2 years ago
if (vlen > 4096) {
VLEN is unitless
8 months ago
bad_isa_string(str, "Spike does not support VLEN > 4096");
Restrict spike to vlen <= 4096
2 years ago
}
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
std::string lowercase = strtolower(priv);
bool user = false, supervisor = false;
if (lowercase == "m")
;
else if (lowercase == "mu")
user = true;
else if (lowercase == "msu")
user = supervisor = true;
else
bad_priv_string(priv);
Keep max_isa and extension_table in sync in exactly one place This fixes a bug where --isa=rv64imafdc would fail to set extension_table['F'] because of the ad hoc manner in which we were synchronizing max_isa and extension_table.
3 years ago
extension_table['U'] = user;
extension_table['S'] = supervisor;
add check for H extension requires S mode (#1042)
4 years ago
Keep max_isa and extension_table in sync in exactly one place This fixes a bug where --isa=rv64imafdc would fail to set extension_table['F'] because of the ad hoc manner in which we were synchronizing max_isa and extension_table.
3 years ago
if (extension_table['H'] && !supervisor)
add check for H extension requires S mode (#1042)
4 years ago
bad_isa_string(str, "'H' extension requires S mode");
Keep max_isa and extension_table in sync in exactly one place This fixes a bug where --isa=rv64imafdc would fail to set extension_table['F'] because of the ad hoc manner in which we were synchronizing max_isa and extension_table.
3 years ago
max_isa = max_xlen == 32 ? reg_t(1) << 30 : reg_t(2) << 62;
for (unsigned char ch = 'A'; ch <= 'Z'; ch++) {
if (extension_table[ch])
max_isa |= 1UL << (ch - 'A');
}
Split isa_parser_t out of processor.* and into its own file (#955) The main motivation for this is that we want to move the ISA parsing logic to run before we even construct a simulator. That's probably a bit nicer if we don't depend on the processor header. It also means that we can stop depending on processor.h in disasm.cc or spike_log_parser.cc (both through disasm.h), which feels a bit cleaner: making sense of an instruction trace shouldn't really require knowledge of the internal state of a processor.
4 years ago
}