Lpc2000

--- In lpc2000@yahoogroups.com, "David Hawkins" <dwh@o...> wrote:
> 
> Hi Charles,
> 
> Thanks for the interesting comments.
> 
> > One argument against leaving things in SVC mode is that you 
> > cannot then do SWIs, since SWIs need to switch to SVC mode to 
> > execute.
> 
> Is that really true? Since an SWI is generated from an instruction,
> you could push the contents of the link register, then call
> an SWI, and then restore the link register? So you could run the
> RTOS from SVC and still use SWIs.

I guess you could do that, but that would add extra overhead to the 
SWI calls.

AFAIK, the problem only applies to a few encodings of ldm/stm that you 
don't use in normal use anyway. Therefore I don't see much need to 
jump through hoops to accomodate it.

> 
> > > Any comments on the store/load-multiple instructions and
> > > issues with their use?
> > 
> > STM and LDM provide nice compact data shuffling, but they can push 
out 
> > interrupt latency since the whole instruction must finish before 
the 
> > interrupt can be serviced. For that reason, some compilers allow 
for 
> > controlling the maximum number of registers save/restored by an 
ldm/stm.
> 
> Good point. But in the case of exception handler prolog and epilog
> code, you'd ideally use those instructions. Even when interrupt
> nesting, its nice to save full context before enabling interrupts of 
> higher priority, ditto for the restore sequence.

For calling APCS compilant (ie. C generated isrs) you do not have to 
save all registers, only r0..r3. The called function will save any 
other registers it needs itself.

The lockout also applies to fiqs too. fiq handling can sometimes be 
done at a very high rate (ie. a few well chosen instructions).