Lpc2000

Robert Adsett wrote:
> 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
> 

You're right, the overhead is exceptable. And it needs less clocks than my current work-around. I
think, I will write a stub tomorrow! ;-)

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/