This commit implements support for the AAMVIRTUAL bit in the abstract memory
access command. When enabled, this bit allows memory accesses to be performed
in virtual address space rather than physical address space.
Changes made:
- Added aamvirtual flag parsing in perform_abstract_memory_access()
- Updated assembly generation to properly handle virtual memory access by
manipulating MSTATUS.MPRV bit
- Added csrrc and csrrw helper functions
Signed-off-by: Farid Khaydari <f.khaydari@syntacore.com>
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.
Farid Khaydari
Andrew Waterman
Kerim Turak
Alexander Romanov
Chih-Min Chao
Parshintsev Anatoly
Ved Shanbhogue