4 ms·

The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not The hardware/IS

by Neywiny 2mo ago

The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not The hardware/ISA matches the ABI. I'm struggling to find the RV doc that describes it on mobile, but I am confident about it. So in RV, there's no pushing required at all which can save time. Interestingly, it looks like GCC (didn't check others) can compile compilation units with only using some registers. So presumably you could implement some compiler-driven banking of registers... Which I'd never thought about and actually is interesting. RV gives you that flexibility. But you really have to work for it. Which goes back to my other comment. NVIC just handles it pretty well. Especially with ARM recommending 64 bit memory alignment for the stack, it allows devices like the STM32H7 to have 64 bit buses on 32-bit CPUs to halve the transfer time. RV can't do that. No hardware memory ops, no multiple load/store. Trade offs, certainly

inigyou 2mo ago
It isn't the CPU that's saving all registers here, it's the interrupt handler code, which, if the author wanted to reduce latency, he wasn't forced to save all registers.
- Neywiny 2mo ago
  It depends. On cortex-m, it is the CPU. On RV, it's the code. However, if your IRQs are within the ABI, you are forced to save some registers. I believe Xilinx is overly aggressive with their saving but you still need to save at least some without hardware assistance.
- RetroTechie 2mo ago
  > if the author wanted to reduce latency, he wasn't forced to save all registers Yup.. If author's working with a RISC-V softcore, there are several options to reduce interrupt latency: # If softcore saves many registers as a hardware feature: adapt it to not do so # Save (and use) only a few registers in interrupt handler # Reserve some registers to be nuked by the interrupt handler, and don't use those in application code # Use another softcore with faster interrupt response # Move to a part with cpu as hard silicon (with sane interrupt handling) Just to name a few (or some combo thereof).

by Neywiny 2mo ago

inigyou 2mo ago

It isn't the CPU that's saving all registers here, it's the interrupt handler code, which, if the author wanted to reduce latency, he wasn't forced to save all registers.

Neywiny 2mo ago
It depends. On cortex-m, it is the CPU. On RV, it's the code. However, if your IRQs are within the ABI, you are forced to save some registers. I believe Xilinx is overly aggressive with their saving but you still need to save at least some without hardware assistance.
RetroTechie 2mo ago
> if the author wanted to reduce latency, he wasn't forced to save all registers Yup.. If author's working with a RISC-V softcore, there are several options to reduce interrupt latency: # If softcore saves many registers as a hardware feature: adapt it to not do so # Save (and use) only a few registers in interrupt handler # Reserve some registers to be nuked by the interrupt handler, and don't use those in application code # Use another softcore with faster interrupt response # Move to a part with cpu as hard silicon (with sane interrupt handling) Just to name a few (or some combo thereof).