-
Notifications
You must be signed in to change notification settings - Fork 878
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Critique of #1853: the new get_csrs
extension method is unnecessary, and has negative side effect
#1863
Comments
Also note that, the initialization of custom CSR's may require access to the processor instance (i.e. to inspect a relevant feature / state of the processor). This is why there is already But the new But this all smells too hacky for a public interface between spike and extensions; and it most likely will confuse extension developers who knows about |
I agree with your critique of #1853 breaking the CSR initialization pattern. As a solution, I disagree that |
If an extension introduces custom CSR's to the processor, isn't it by definition modifying (extending) the processor's state? The bright side of With your proposed solution, extensions developers would have to dig into spike's internal implementation (not just public interfaces) to find out that |
This addresses one issue raised in #1863. register_extension() is only called once, while reset() is called whenever the processor_t is reset. This ensures that extension_t state, including CSRs, is always reset with reset()
Yes, but that doesn't mean that the
I don't quite understand this critique, I've implemented #1864 for now |
Hi @jerryz123, this is more of a call-for-clarification than critique. You see, there is already Then this p.s. #1864 looks good to me. |
I think I just underestimate the complexity of It does seem like
This approach seems best to me. |
Looks like
In my case, we sometimes want to overwrite spike's builtin instruction / CSR implementations through extension modules to align the behaviors of SIM to RTL. Take #528 for example, we want p.s. I have created a Python-binding for Spike. It allows users to write ISA extensions and MMIO device models in Python, and plug them into Spike through |
@arrv-sc FYI |
Ok, this is an interesting use case. I assumed all uses of extension_t were simply adding new instructions or CSRs, not modifying the behavior of standard instructions. |
Hi @jerryz123, do you think it's time to take on this approach to refactoring the public interface of |
Hi! I like the Idea of re-inserting csrs on
I like this approach and its explicitness. If we are not afraid of compatibility issues I am willing to implement the refactoring |
Regarding |
Thanks, @arrv-sc , I'm happy to review again if you PR the refactor. I'm not concerned about compatibility issues. Yes, the intention is for custom extensions to call |
PR #1853 added a new
get_csrs
method to the public interface ofextension_t
, claiming to solve the alleged problem that "adding custom CSR's from extension modules was impossible". This was a false claim -- we don't need a new method for this (explained below) -- worse still, PR #1853 introduced a negative side effect causing changed CSR states to survive processor reset.Before #1853, it was indeed possible to add custom CSR's from the
extension_t::reset()
method, i.e.,This does not require changing the public interface of extensions. And it ensures custom CSR's resume to their default states upon processor reset. We should keep it the old way.
In fact, all standard CSR's are being (re-)added during processor reset (call path
processor_t::reset()
->state_t::reset()
->csr_init()
). When we add custom CSR's fromextension_t::reset
, they equally have a chance of being reset (re-added) during processor reset (call pathprocessor_t::reset()
->extension_t::reset()
).IMHO, what we actually need is an example of adding custom CSR's from extensions, and CI tests to make sure this works (PR #1853 has its merits in this regard). But changes to
extension.h
andprocessor.cc
should perhaps be reverted.The text was updated successfully, but these errors were encountered: