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