Re: ISR-support in ARM

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Richard Slaughter wrote:
> 
> Kai,
> 
> The current release of 3.0.2 and snapshot I used was recognizing the
> interrupt keyword and generating ISR code.   I "assumed" it was correct.
> I'm using the atmel AT91FR40807 processor and with the debugger I was
> getting
> interrupts and returning correctly.
> 
> I didn't anaylsis the interrupt handler as closely as I should have
> and missed the r12 register usage.
> 
> I don't understand how you concluded that the GCC ISR works
> for the atmel AT91.  It seems to me that r12 is overwritten.

 I wrote somehow unclear, but my conclusion was the opposite... I have the
examples from Atmel for the assembly wrappers and there are quite a lot
extra things to do like in the prologue :

;- Adjust and save LR_irq mode in IRQ stack
            sub         r14, r14, #4
            stmfd       sp!, {r14}

;- Save SPSR and r0 in IRQ stack
            mrs         r14, SPSR
            stmfd       sp!, {r0, r14}

;- Enable Interrupt and Switch in SYS Mode
            mrs         r14, CPSR
            bic         r14, r14, #I_BIT
            orr         r14, r14, #ARM_MODE_SYS
            msr         CPSR_c, r14

;- Save scratch/used registers and LR in User Stack
            IF  "$reg" = ""
            stmfd       sp!, { r1-r3, r12, r14}
            ELSE
            stmfd       sp!, { r1-r3, $reg, r12, r14}
            ENDIF

 What I have used to with other CPUs is that these kind of things can be
put into the prologue GCC generates, while with ARM it isn't so clear
what to put there...

 Having these things for AT91 enables making a GCC which is specific for
AT91, or some of those '-m<something>' options could trigger a target switch
which then causes the proper prologue/epilogue being generated for the
target... But how many 'targets' there are for whom those 'complete'
prologues and epilogues could be produced?

 As seen, the gcc-3.0.2 approach leaves out the tinkering with the various
stacks, interrupt enabling (for nested interrupts) and so on... So one must
produce proper wrappers in assembly for the ARM-type one uses, and I would
expect some generic advices for the newbies about what these wrappers should
or should not save/restore, for instance one could now imagine the 'fp' and
'ip' saving/restoring happening in these wrappers and only the overwiting of
the 'lr' (r14) being a bug...

Cheers, Kai

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com