0

I'm going through how FIQ works on ARM and came across the statement that FIQ should always be written in assembly not in C but couldn't understand why?

I have gone through the following link

http://comments.gmane.org/gmane.linux.ports.arm.kernel/14004

But still couldn't make out why is it required?

Can any one please point me out the need of writing FIQ in assembly through some example?

Amit Singh Tomar
  • 8,380
  • 27
  • 120
  • 199
  • As the last two posts in the discussion point out, it's not _required_, it just makes very little sense not to. Note also that the discussion is strictly within the context of Linux. – Notlikethat Feb 24 '15 at 15:05
  • One issue is the context switch back to the interrupted mode, which could be IRQ, Supervisor, System, User, ... , which requires special instructions, but those could be implemented as intrinsics or library calls. Another issue is speed and taking advantage of the shadow copy of R8-R14, but it's possible that compiler extensions could use these for variables declared as "FIQ" register types. – rcgldr Feb 24 '15 at 15:51
  • Your question is ambiguous. The discussion above is for Linux. In 2004, Linux has no FIQ stack. You **may** have a FIQ stack if you set it up yourself. It is not actually clear what your want nor what you have tried. You may not easily handle a FIQ in 'C', just like an IRQ as the ARM vector table needs branches. You need at least a stub or 'C' extension and linker magic. In theory it is possible with gcc and some extensions; at least to make a FIQ that returns immediately. Whatever you read on the Internet is not always true and often depends on context. – artless noise Feb 24 '15 at 21:50
  • It may be worth noting that the _original_ context for FIQ mode was supporting unbuffered peripherals where data was only valid for a certain number of cycles, and memory was slow enough that by the time you'd pushed a couple of registers to the stack to preserve them, the device data that you took the interrupt for was already lost - before you'd even _tried_ to read it. Hence the addition of extra banked registers. Of course, that was 30 years ago, modern systems are rather different. – Notlikethat Feb 24 '15 at 23:41
  • @Notlikethat Kudos, I just learned first arm chip was 30 years ago and supported FIQ. – auselen Feb 25 '15 at 07:18
  • There are simply things that have to be written in assembly. There are also many things that are the easiest, most convenient to write in assembly. – Jake 'Alquimista' LEE Feb 25 '15 at 12:39

2 Answers2

2

My guess is based on this:

Also, it's a little difficult to write the FIQ code in C, since you lack a stack :)

If there's no stack, that would mean that the compiler is restricted to only using registers for all variables, which I'm not sure how you'd even express.

You can put register on all the local variables, but that doesn't mean that the compiler has to comply.

Writing the code in assembly of course goes around this restriction, and makes it possible to combine registers and global state to do things.

See also this question's answers for more about the difference between an ordinary interrupt and a fast one.

Community
  • 1
  • 1
unwind
  • 391,730
  • 64
  • 469
  • 606
  • Without a stack, you also only have 5 registers you can even touch (well, 7 if you abuse sp and lr), because you've nowhere to preserve the others. Try convincing a C compiler to play within those rules ;) – Notlikethat Feb 24 '15 at 15:08
  • I don't see the problem with swapping to a FIQ-specific stack? There is only one FIQ, so should not be a problem. I haven't actually tried this - I've manged to get away with assembler and R8-13 with my FIQ so far:) – Martin James Feb 24 '15 at 15:09
  • Stay away from libraries under interrupt. As FIQ will interrupt normal IRQ handlers, whose authors will probably consider to be time critical too, a high priority interrupt needs to be written with fast, clean, lean code, exactly as the skilled programmer intends it to be. – Weather Vane Feb 24 '15 at 15:11
  • I really didn't get this point writing FIQ in C,we lack a stack? – Amit Singh Tomar Feb 24 '15 at 15:12
  • @AmitSinghTomar - FIQ has no inherent stack context. You would have to provide your own static/global stack area and swap to it. – Martin James Feb 24 '15 at 15:14
  • Also, with non-trivial systems, it would have to be non-paged. Prolly best to have the linker dedicate a specific section to it at build time. – Martin James Feb 24 '15 at 15:19
  • 1
    Each ARM mode has it's own shadow copy of R13 (except user and system modes share the same set of registers), so during initialization, the code switches to each mode and sets that mode's R13 to that mode's stack, so each mode, including FIQ, has it's own stack. – rcgldr Feb 24 '15 at 15:46
2

Because what is the point, you are using an extra bank of registers to save a handful of clock cycles in saving the state, then to use C and completely blow that tiny cost savings? If you are not interested in optimizing to that level then dont bother with fiq just use irq.

old_timer
  • 69,149
  • 8
  • 89
  • 168