Hacker News Reader

Comment by inigyou | Hacker News Reader

Don't you have to save registers on any architecture, or not use them in the interrupt handler?

No. That's also partially in the article. But even in ones that do, usually it's a subset. In arm-m, some registers get stacked on interrupt (basically the caller saved ones in the ABI so any regular functio is automatically IRQ compatible). In this implementation, 64 registers do. Very different from I think it's r0-r3, lr, and pc. Some architectures bank them, so as long as you don't nest or call functions you can just use the interrupt bank.

RV actually allows for that. But not dictating that registers get pushed to the stack, flexibility in how you manage them opens up. So for RV, and some other architectures, you have to mark the function an IRQ and the compiler will know how to figure that out.

Another gotcha is that for AXI and other burst interfaces, the hardware being able to say "I'm going to send you X words" is dramatically better for latency than each one being a single transaction. So if your stack is in a location that requires multi-cycle memory access times, this balloons in timing cost.

Sadly this is a very hard topic to condense into a few sentences. Maybe if I wrote an article on it with graphics it would help. Unsure

Are all registers caller-saved in RISC-V, or are you blaming the ISA for a specific inefficient implementation and ABI?

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

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.

> 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).

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.

Reply on news.ycombinator.com