This commit implements the abstract memory read/write commands in the debug module. The changes include:
- Added support for abstract memory access commands (cmdtype 2) in perform_abstract_command()
- Implemented perform_abstract_memory_access() method to handle memory operations
Signed-off-by: Farid Khaydari <f.khaydari@syntacore.com>
This commit adds support for configuring the number of data registers available
in the debug module. Previously, the debug module had a fixed datasize of 2,
but now users can specify the number of data registers using the --dm-datacount
option when running spike.
The changes include:
- Adding a datacount parameter to debug_module_config_t
- Making dmdata a std::vector instead of a fixed array
- Validating that datacount is between 1 and 12
- Updating the debug module to use the configured datacount
- Adding command-line option to set datacount
- Updating documentation in help output
Signed-off-by: Farid Khaydari <f.khaydari@syntacore.com>
Prior to this commit vectorUnit_t::elt was a bottleneck for vector
instructions performance. This function was not being inlined because
the definition was inside a .cc file. After moving the definition to the
header file I measured the 20-30% increase in performance on random
vector test from CI.
This commits adds basic spike testing using llvm-snippy random code
generator. This initial testing runs spike on random valid code snippets and
checks that it doesn't fail.
Co-authored-by: Ksenia Dobrovolskaya <ksenia.dobrovolskaya@syntacore.com>
Building of spike-based simulator with memory sanitizer reports leaking
pointers if custom extension are used. This is because existing
facilities do not have a proper destructor procedure, so the objects
representing custom extentions are leaked. This commit implements
quick-and-dirty fix for the problem.
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.