ISA Multiple Inheritance

[Jozott00]

Currently, VADL ISAs support single inheritance, allowing one ISA to extend another. However, architectures with ISA extensions that do not have a linear dependency structure are difficult to model.

Consider RISC-V 64 with its standard-extensions:

Arrows mark dependencies. All those extensions are combinable.

One inaccuracy in this diagram is the optional dependency of Zicsr on RV64I, which provides control and status registers. If a processor does not implement Zicsr, the ECALL and EBREAK instructions behave as NOPs. However, if Zicsr is present, they trigger an exception that modifies control and status registers, enabling privilege mode transitions.

This extension system cannot be accurately modeled with single inheritance. Defining processors with different extension variations would lead to significant ISA duplication.

However, using multiple inheritance it could look like this

instruction set architecture RV64IBase = {
	program counter PC
	register file X
	memory MEM
	
	// RV64I instructions (except ECALL, EBREAK)
}

instruction set architecure RV64I extends RV64IBase = {
	// ECALL and EBreak as NOP
}

instruction set architecture RV64IZicsr extends RV64IBase = {
	// status and control register
	// instructions + ECALL and EBREAK 
}

instruction set architecture RV64M extends RV64IBase = {}
instruction set architecture RV64V extends RV64IBase = {}
instruction set architecture RV64A extends RV64IBase = {}
instruction set architecture RV64F extends RV64IBase = {}
instruction set architecture RV64D extends RV64F = {}

Now if the user wants to define a processor supporting RV64IM they can do this by

instruction set architecture RV64IM extends RV64I, RV64M = {
	// nothing to do here
}
processor CPU implements RV64IM = {}

And if they want CSR, Vector and Atomic instructions but no multiplication in another processor they would use

instruction set architecture RV64IAVZicsr extends RV64IZicsr, RV64A, RV64V = {
	// nothing to do here
}
processor CPU implements RV64IAVZicsr = {}

Restrictions

To determine the constraints under which multiple inheritance is feasible in our ISA specification, consider merging all dependencies of an ISA into the root one. (EDIT: The root is the ISA actually used by the generator, e.g. RV64IAVZicsr in the upper example)
This merged ISA is valid if:

• Single Program Counter (PC): Exactly one PC counter exists.
• No Naming Conflicts: There are no duplicated definitions, such as two register files sharing the same name.

For the ISS, these conditions seem sufficient.
Since we don’t support definition overriding (as in method overriding in OOP), implementing multiple inheritance should be straightforward.

However, I am sure that I forgot something.

---

NOTE: This is transferred from Gitea.

[Jozott00]

Implemented in #238