Hello *,
does it make sense to make the IRQ vector bigger than the given 0x80 in order to handle the IRQ in place instead of branching off to a different location and handle it there. Assume your OS never traps an FIQ, the FIQ vector space could be used to have a bigger IRQ handler (0x160). I recently came across this in an OS and was shocked that someone does this for "performance reasons". But I want to have other opinions on this. Do you think it has a big performance impact to directly branch off from the vector to a different location to handler the IRQ there, versus doing the handling directly at the IRQ vector. I can't believe that this has such a big impact on the interrupt latency or does it?Also for safety reasons isn't it really stupid, if for any reason an FIQ is trapped anyway, because it was enabled by some driver or so and it would then jump into the middle of the IRQ vector most likely crashing the OS?!
Not sure where the "0x80" comes from, but I guess you talk about Armv8-A AArch32, as AArch64 does not have FIQ.Anyway, I agree, I would not spread IRQ code across the FIQ vector address. The very small performance gain does not pay off a weird crash.
BTW: The place for the FIQ was chosen for performance reasons: No jump needed to handle FIQ.
I'm talking about the exception vector table for AArch64, which has an FIQ vector (@offsets 0x100, 0x300, 0x500 and 0x700 depending on the mode that was executing before), which comes directly after the IRQ vector (and is 0x80 in size, as all the other vectors). And on AArch32 you're right, the FIQ is the last vector so no need to branch off. But ok you agree that for the small performance gain is not worth having the risk of a weird crash...
deathjester said:I'm talking about the exception vector table for AArch64, which has an FIQ vector (@offsets 0x100, 0x300, 0x500 and 0x700 depending on the mode that was executing before),
You are right. I stand corrected.