Closed wysiwyng closed 7 months ago
As discussed in #116 I would agree with the position that "exiting on loop to self" is not a good idea.
The
wfi
is not defined to must set the hart to sleep, i.e., is implementation specific. I also do not think it is a bad take to force the application code to decide when to exit the simulation, e.g., by semihosting +ecall
s. However, most importantly the self-loop-exit behavior is not described in any standard and will/might lead to problems in future scenarios.
Just saw that in the commit https://github.com/tum-ei-eda/etiss/pull/127/commits/44f695f25d9a11f8ea34cd35e8985da25c01ffc3 the "exit-on-loop-to-self" was made optional with a configuration setting. All good. :+1:
Converted to draft until interrupt support is ready
New updates:
InterruptEnable
class to query a global interrupt enable flag in ETISS' InterruptHandler
pluginM/SSTATUS
CSRs, floating point instructionsriscv-tests
related to MMU, CSR and breakpoints fail, all others passTested the interrupt handling for edge-triggered peripheral interrupts in the etiss-sc project with your PR branch. Looks good and works with the fixes mentioned in the review comments above.
This adds updates to the RV32 and RV64 architecture models, namely:
CodeParts
feature, allowing plugins to better insert their own JIT-CodeInterrupt support of these architecture models is currently untested and probably not implemented correctly. Adding interrupt support would be a matter of extending the trap entry function in CoreDSL to handle incoming interrupts, as well as extending ETISS to generate a corresponding call to said trap entry function.
RV64M needs 128 bit arithmetic, this is not supported per se in ETISS, see also #107. This patch uses the GCC
__[u]int128_t
types for limited support until a better solution is found. Because of this, RV64M only works when using GCC or LLVM as JIT engine, as TCC has no 128-bit arithmetic support.