Lpc2000

At 09:33 PM 3/25/2006 +0100, Sten wrote:
>Robert Adsett wrote:
> > At 08:17 PM 3/25/2006 +0100, Sten wrote:
> >
> >>Robert Adsett wrote:
> >>
> >>>Rather than go through all this hand-wringing why not just write an
> >>>assembly stub?  You'd know it was correct and you'd be done already.  At
> >>>most it would cost you an extra call from the stub to your C
> >>>function.  Heck if it was small enough it might make sense to do the whole
> >>>thing in asm.  For that matter you could steal one of my stubs.
> >>
> >>At the moment I declare my IRQ functions as "naked" and write my own
> >>prologue/epilogue with inline
> >>assembler. But it is less efficient because I don't know which registers
> >>are really used, so I have
> >>to save all non-banked registers (r0..12 for IRQ and r0..r7 for FIQ) which
> >>is a wast of performance.
> >
> >
> >
> > If you write a stub that problem disappears. The procedure call standard
> > ensures that the proper registers are saved when you call out of the stub.
> > You only have to save something like 6 registers for IRQ, the called
> > routine preserves any of the others it uses..
> >
> > Also are you sure you actually really care about the extra saves?  Beware
> > of premature optimization.  Didn't Knuth call it the root of all evil?
> > :)  If your response time is sufficient and your are not overloading the
> > CPU forget about the wasted cycles, you are spending time doing something
> > that simply does not matter.
> >
> > I do a stub not for efficiency but because experience has taught me to
> > never trust any compiler to produce correct interrupt code.  Correct does
> > sometimes mean efficient but it can also mean the more obvious things.
> >
> > Robert
>
>Ok, what exactly did you mean by a "stub"? You write a piece of assembler 
>code for a particular IRQ
>and then branch to your (normal) C service function, don't you?

As a matter of fact, yes.  That would be a stub.

>I'm thinking of writing a generic IRQ handler instead of a direct branch 
>to VIC-vector register from
>vector table, I'm using at the moment. This IRQ handler (in clean 
>assembler) could have correct
>entry and exit code and is branching to the service function from 
>VIC-vector. The overhead would be
>very less.

That would also be a stub.  I don't see any reason off hand not to do it 
that way although I also don't see that it will change the overhead at all.

branch to irq source specific stub
save registers
call service function

versus

branch to stub
save registers
call irq source specific function

Since you cannot take advantage of the 'wrap-around indexing' into the VIC 
table it might even be a little more overhead in the second case.  I doubt 
it matters in most cases and I can see some real clarity advantages to 
doing it that way.  Hmmmm....

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/