[proposal] define a fuller EABI for EL sub-profile

[jnk0le]

The current RV32/64I EABI looks like being overoptimized for a specific single issue pipeline design (and instruction memory latency) by sacrificing the overall ABI performance in favour of achieving best interrupt latency with reasonable stacking for direct C/C++ compatibility. It seems to be good approach for entry level microcontrolers (ES, EM), but superscalar micros and "not-yet-application-processors" (EL) comparable to cortex-m7 and cortex-R, will be underutilized in both; the overall ABI performance and interrupt stacking where just the pipeline refill is longer than stacking 4-6+2 registers in just 3-4 cycles.

Therefore I propose to officially define an fuller EABI for EL sub-profile in 2 possible ways:

a) Define yet another ABI overoptimized now for eg. a specific dual issue pipeline design. b) Recycle POSIX ABI that currently have to stack 16+2 integer registers, so the stacking itself will take 9 cycles on dual issuers.

Since defining multiple not compatible ABIs is not something what we want to do, I would personally pick the second approach.

As to avoid fragmentation within sub-profiles I also propose to add an atomic extension and multi-harting capability for the EM sub-profile (of course optional).

[ilg-ul]

Hi @jnk0le, I'm greateful you are taking your time to make these proposals, but, as you are probably aware, general interrest for a RISC-V microcontroller profile is currently not very encouraging, at least at official level.

As for the ABIs, realistically there will be no EABI without the blessing of the Foundation, and without its support to change the compiler.

For the large micros I see no problem to use the current ABI; even more, since for the large micros the transistor counts should not be an issue, I can also imagine the ABI selection to happen at run-time, via a configuration bit.

Unfortunately none of these concerns are reflected in the current Foundation work, for example see CLIC, the new interrupt controller.

[jnk0le]

It's just like with every other extension without money from big corpos chairing TGs.

The CLIC seems to be just another extension to prior unix-like interrupt handlers. Paragraphs 6.2 and 7.1 of the CLIC, shows exactly what we want to avoid with full hardware approach.

[ilg-ul]

Yeah... the only good news is that the new specs, currently under review before ratification, will slightly loosen the dependency from the privileged specs, and, although the Foundation is not at all happy about this, it'll be easier to imagine a separate microcontroller RISC-V profile.

In thise conditions, what do you think about a custom QEMU to implement an experimental microcontroller profile?

[jnk0le]

I'm not familiar with QUEMU, so can't tell whether it is a good environment to evaluate mostly uncore part.

[ilg-ul]

I'm not familiar with QUEMU

maybe it would be useful to run the blinky tutorial to the end, including running the app on the emulated stm32f4-discovery, to have an idea what can be done with QEMU.

the point is that something similar can be done for a set of virtual boards using RISC-V virtual devices, in order to experiment various choices for the microcontroller specs, before considering Verilog/VHDL implementations.