28 ms·

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/st

by Neywiny 2mo ago

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/riscv/trap_handler.S https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw and hardware options) to get it to operate more like arm-m, but arm-m doesn't need that work to be done. NVIC is always NVIC, and NVIC is good

wren6991 2mo ago
Yeah, this is a bug. They should only be saving the FP state if it's dirty. Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.
- Neywiny 2mo ago
  Not a bug, just not optimized. Because I think there's a csr to read it the fpu is dirty but... That requires csr extension. It would also increase jitter, which in some cases is more important. At best it should be still there as an option, but also optionally improved
  - wren6991 2mo ago
    Fair enough. It's a performance issue but not a functional correctness issue. > Because I think there's a csr to read it the fpu is dirty but... That requires csr extension Yes, and they already unconditionally read that CSR :-) The "CSR extension" is an almost 100% theoretical concern. It was the spec authors being defensive in case the privileged ISA was so flawed they had to throw it out in future, while keeping the base ISA. I don't see that happening at this point. The only exception is deeply embedded cores that drop even basic IRQ and exception support. These are always going to exist and I think they're a sufficiently separate class of processor that they don't really factor into the compatibility equation, because such processors usually only run one program in their entire lives.
    - Neywiny 2mo ago
      You know what, you're right. I was thinking of the timer option. I don't think you can turn off the csr functions on that core. But I've gotten into trouble turning off the timer
  - IshKebab 2mo ago
    > That requires csr extension. Interrupts require the CSR extension. In practice all RISC-V CPUs support Zicsr.
mycall 2mo ago
You can bypass AMD's heavy BSP abstractions according to gpt.
- Neywiny 2mo ago
  Is that what you think that is here?
inigyou 2mo ago
Don't you have to save registers on any architecture, or not use them in the interrupt handler?
- Neywiny 2mo ago
  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
  - inigyou 2mo ago
    Are all registers caller-saved in RISC-V, or are you blaming the ISA for a specific inefficient implementation and ABI?
    - 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

by Neywiny 2mo ago

wren6991 2mo ago

Yeah, this is a bug. They should only be saving the FP state if it's dirty. Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.

Neywiny 2mo ago
Not a bug, just not optimized. Because I think there's a csr to read it the fpu is dirty but... That requires csr extension. It would also increase jitter, which in some cases is more important. At best it should be still there as an option, but also optionally improved
- wren6991 2mo ago
  Fair enough. It's a performance issue but not a functional correctness issue. > Because I think there's a csr to read it the fpu is dirty but... That requires csr extension Yes, and they already unconditionally read that CSR :-) The "CSR extension" is an almost 100% theoretical concern. It was the spec authors being defensive in case the privileged ISA was so flawed they had to throw it out in future, while keeping the base ISA. I don't see that happening at this point. The only exception is deeply embedded cores that drop even basic IRQ and exception support. These are always going to exist and I think they're a sufficiently separate class of processor that they don't really factor into the compatibility equation, because such processors usually only run one program in their entire lives.
  - Neywiny 2mo ago
    You know what, you're right. I was thinking of the timer option. I don't think you can turn off the csr functions on that core. But I've gotten into trouble turning off the timer
- IshKebab 2mo ago
  > That requires csr extension. Interrupts require the CSR extension. In practice all RISC-V CPUs support Zicsr.

mycall 2mo ago

You can bypass AMD's heavy BSP abstractions according to gpt.

Neywiny 2mo ago
Is that what you think that is here?

inigyou 2mo ago

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

Neywiny 2mo ago
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
- inigyou 2mo ago
  Are all registers caller-saved in RISC-V, or are you blaming the ISA for a specific inefficient implementation and ABI?
  - 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