feat: add possibility for custom CSRs

[arrv-sc]

Currently in riscv-isa-sim there's no way to make a custom extension that adds new CSRs. This simple patch makes it possible via new virtual function in extension_t class.

[arrv-sc]

@aswaterman @jerryz123, could you please take a look

[jerryz123]

This change looks good. @arrv-sc are you able to identify what might be causing the regression failure? It isn't obvious to me.

[arrv-sc]

@jerryz123 I added new target to create-ci-binary-tarball script. Testing script fetches tar archive with binaries compiled for riscv and then executes them. Pipeline fails because archive does not contain executable compiled from my new customcsr.c file. As far as I know this tarball has to be updated manually and I cannot do that.

[jerryz123]

Ah right, I'll upload the updated tar soon.

[aswaterman]

LGTM, too.

[arrv-sc]

@aswaterman there is also a question of whether or not we should check for overwriting standard CSRs with custom ones that use the same addresses. In this commit I didn't implemented this check as it turned out to require some refactoring and I didn't want to make this change too big. Should we implement it after all?
Also after consulting with RISC-V spec I couldn't understand if custom extensions can reuse standard CSR addresses if corresponding standard extension is not enabled. Can you shed some light on this please?

[aswaterman]

Non-conforming extensions can use standard CSR addresses, but only if the address is not used by a standard extension that the implementation claims to support. For example, the address of fcsr can be reused by a custom extension only if the F and Zfinx extensions are not implemented.

IMO, extending Spike is a feature for experts, so the error checking would be nice to have, but is not absolutely necessary. If the refactoring is very messy, I would be OK with skipping it.

[liuyu81]

It was always possible to add custom CSR's from the reset() extension method, i.e.,

void myextension_t::reset() {
    this->p->get_state()->add_csr(...);
}

All standard CSR's are being (re-)added during processor reset (call path processor_t::reset() -> state_t::reset() -> csr_init()). I guess this makes sense, because CSR's have states, and we want them to restore to their default states upon processor reset. If we add custom CSR's from extension_t::reset, they equally have a chance of being reset (re-added) during processor reset (call path processor_t::reset() -> extension_t::reset()) -- and the public interface of extensions can remain intact.

With this PR, however, the custom CSR's are added once for all during extension registration, and changed states may last till after processor reset.

IMHO, the new get_csrs() extension method of this PR, is a little bit of a redundancy, yet with negative side effect.

[arrv-sc]

@liuyu81 You are making a valid point. We can avoid this side effect by re-initializing CSRs from extensions in processor_t::reset

[liuyu81]

hi @arrv-sc, I like it that you added new CI tests to make sure custom CSR's work.

Regarding this PR, my point is, if we can contain the change to our own extensions (without invading into spike's code base), why bother changing / extending the public interface between spike and extensions?