Interrupt latency benchmarking on CH32V003 w/ and w/o hardware-stacking (HPE)

[bson]

This is because you call the standard C function foo().  And so everything has to be saved, in case foo() nukes it.

Does the RV ABI used mandate this?  Normally in other ABIs a called function saves any registers it modifies, so he should be fine with a minimal saved set.

[brucehoult]

This is because you call the standard C function foo().  And so everything has to be saved, in case foo() nukes it.

Does the RV ABI used mandate this?

Absolutely!

Any function following the standard RISC-V ABI is free to nuke registers a0-a7, and t0-t6.

Normally in other ABIs a called function saves any registers it modifies, so he should be fine with a minimal saved set.

That is not correct:

32 bit Arm: functions are free to nuke r0-r3, r12, r14 (LR)

64 bit Arm: functions are free to nuke x0-x17, x18 (PR) if not reserved by the platform

64 bit x86: functions are free to nuke rax, rcx, rdx, rsi, rdi, r8-r11 (SysV e.g. Linux/Mac)

AVR: functions are free to nuke r0, r18-r27, r30-r31

PowerPC: functions are free to nuke r0, r3-r12

MSP430: functions are free to nuke r11-r15


Perhaps you were thinking of ancient (and inefficient) ABIs that pass arguments and function results on the stack, such as VAX, M68000, and (most) 32 bit x86 calling conventions?

I don't think any ABI designed since about 1985 requires called functions to preserve all registers.

[NorthGuy]

Strange that they save registers for the interrupts in the stack in such a modern design. There are better ways. You can use shadow register sets and such. Even PIC16s are doing this (and have been doing this for 10 years or so), so the interrupt latency is 500 ns (for 8 MHz CPU cycle), faster than what you measured for HPE.

[SiliconWizard]

Strange that they save registers for the interrupts in the stack in such a modern design. There are better ways. You can use shadow register sets and such. Even PIC16s are doing this (and have been doing this for 10 years or so), so the interrupt latency is 500 ns (for 8 MHz CPU cycle), faster than what you measured for HPE.

Shadow registers are a whole rabbit hole with - in general - more critics these days than supporters.
Regarding RISC-V, keep in mind the base ISA is meant to be as barebones as possible while allowing extending it easily.

Nothing would prevent a RISC-V extension to include shadow registers, and in fact there may be one out there that I don't know of.
Meanwhile, vendors are free to implement extensions as they see fit and shadow registers is not something that I think I've seen at this point for RISC-V MCUs.

Then there is the very recurring topic of interrupt latency on "modern" MCUs.
Shaving off a few cycles on something running @100MHz+ with single-cycle instructions - for the most part - doesn't necessarily bring much to the table. It was obviously much more critical on a few-MHz MCU with 4-cycle instructions.

And, as some of us often say, if you need ultra-low latency for some very low-level function, you're usually better served with dedicated peripherals these days, and many modern MCU even have hardware triggers that make the need for very-low latency interrupts even less relevant. Outside maybe of some very niche stuff.

Now to be fair, RISC-V MCUs are still relatively few and often not as featureful as the more established ones when it comes to peripherals, hardware triggers and such. But that will come.

[brucehoult]

The message you replied to is pointing out that there is ALSO a NON-vectored mode. which is used by many systems, especially those running Linux or similar on >1 GHz CPUs, where you don't care about shaving nanoseconds off the interrupt response times and you usually have some simple 32 or 64 bit auxiliary CPU core to handle real-time tasks.

Sure,  but the part I was actually replying to didn't make it obvious you were talking about very fast systems when the whole topic was about MCUs.

I wasn't. MCUs also have the non-vectored mode.

And on a MCU running at a few tens of MHz, having to check the interrupt flag in xcause, then test against the exception code and execute code based on that when you have a number of possible interrupt sources, that sure wouldn't be insignificant.

The total time to save registers and branch on mcause is comparable to the interrupt response time on Cortex-M0+ or M3.

[brucehoult]

Strange that they save registers for the interrupts in the stack in such a modern design. There are better ways. You can use shadow register sets and such. Even PIC16s are doing this (and have been doing this for 10 years or so), so the interrupt latency is 500 ns (for 8 MHz CPU cycle), faster than what you measured for HPE.

We are talking about the smallest cheapest core here. If you want shadow register sets then spend a few cents more on a CH32V3xx instead of the CH32V003. The same HPE set-up code and interrupt handler code works transparently on either.

Shadow register sets are not for free. They use a lot of transistors which could be spent on something else, or not spent at all. It makes little sense to cut the register set down from 32 to 16 to save transistors, and then spent a ton of transistors on having multiple sets of them!

Not every application needs 10ns interrupt response time, or even sub µs. We used to achieve a lot with 1 MHz 6502 and 8 MHz M68000, both of which are around 6 µs to execute the first instruction of an interrupt handler.

[brucehoult]

Nothing would prevent a RISC-V extension to include shadow registers, and in fact there may be one out there that I don't know of.
Meanwhile, vendors are free to implement extensions as they see fit and shadow registers is not something that I think I've seen at this point for RISC-V MCUs.

WCH's other, higher end, MCUs have shadow register sets for the HPE feature instead of writing the registers to the stack. The CH32V3xx series, for example.

This is their cheapest, most cut down, one, remember?