IRQ Handler Branch

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?!

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

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

Children
More questions in this forum
There are no posts to show. This could be because there are no posts in this forum or due to a filter.