-1

in arm7tdmi, suppose instruction is being executed and at same time FIQ and IRQ both occur at same time.now according to priority FIQ will be handled then IRQ but my question is that how it will handled IRQ after return from FIQ i means what will be process done at return of FIQ and how control will be transferred to IRQ handler after return statement of FIQ handler ?

example : address => instruction

  0x00000100              :      MOV R0,R1
  0x00000104              :      MOV R0,R1
 =>> 0x00000108              :      MOV R0,R1   
  0x00000110              :      MOV R0,R1
  0x00000114              :      MOV R0,R1
  0x00000118              :      MOV R0,R1

;suppose at 0x00000108 is instructionbeing executed and FIQ and IRQ are raised at time

Neil Terminator
  • 41
  • 4
  • If the IRQ is still pending, then it'll just be taken as normal immediately after the FIQ handler returns (assuming said handler doesn't do anything crazy like manually unmasking IRQs itself between acking the FIQ and returning). What exactly are you seeking clarification of? – Notlikethat Sep 25 '16 at 18:28
  • see whatever current instuciton being executed will be executed befroe going to FIQ handller now on the execution of return instruciton of FIQ handeller normally what happes is copying of r14_FIQ and spsr_FIQ to the pc and cpsr of mode in which it was raised.not suppose IRQ is also pending then what will be the process done after execution of return instruction in FIQ, i mean will it execute one institution in user mode and then IRQ will be handled or directly r14_FIQ and spsr_FIQ will get copied to R14_IRQ and spsr_FIQ to spsr_IRQ? – Neil Terminator Sep 26 '16 at 07:35
  • The word you're looking for is *tailchaining*. If a lower-or-equal-priority interrupt is pending during the execution of a higher-priority one, the core will jump straight to it afterwards, no user code executed. – Andrea Biondo Sep 26 '16 at 09:17
  • thanks @ Andrea Biondo i understood what you explained but i want to know steps what are to be performed on return instruction of FIQ.i mean what are steps involved in transfering control from FIQ_HANDLER to IRQ_HANDLER om tailchaining? – Neil Terminator Sep 26 '16 at 09:28

1 Answers1

1

Unlike the M-profile architectures, with their very different exception model which does permit tail-chaining exceptions, the classic/A-profile architectures do things in a completely straightforward manner.

Interrupts are checked for at instruction boundaries, when the respective CPSR.F/CPSR.I bits is clear. Thus, assuming the FIQ handler is straightforward, once the instruction at 0x108 completes, the FIQ is taken (as it has priority over the IRQ) from whatever mode the CPU was in, the FIQ handler runs with FIQs and IRQs masked, then performs an exception return to 0x110. The fact that there happened to be an IRQ pending throughout makes no difference whatsoever.

The point of note is the boundary between the return instruction at the end of the FIQ handler and the one being returned to. The FIQ return will restore the previous SPSR, which (presumably) has IRQs unmasked. Thus, after executing that return instruction but before executing the one at 0x110, the CPU is back in the initial mode, with IRQs unmasked, and an IRQ pending. So it takes it; the IRQ handler runs with IRQs masked, then performs an exception return to 0x110, whereupon execution eventually continues having served both interrupts.

For ARM7TDMI, that's really all there is to it. In newer architecture versions (ARMv7 onwards), there are some rules tightening up precisely when asynchronous exceptions are expected to be taken, since once CPU designs start becoming superscalar and/or out-of-order the notion of "instruction boundary" gets a bit blurry. This particular situation, though, would be no different on modern CPUs, as the exception return from FIQ constitutes a context-synchronising event after which any pending asynchronous exception (i.e. the IRQ) must be immediately taken.

Notlikethat
  • 20,095
  • 3
  • 40
  • 77