Page 1 of 1

Interrupt handling

Posted: 30 Dec 2007 16:43
by faramir
I psoted this in form of a question some time ago but received no reply, therefore I decided to rephrase it as a couple of suggestions:

1: Add a directive that instructs the compiler not to push&pop certain registers when an interrupt occurs. This is similar to how register handling is done on VAX, for those of you who're familar with VAX assembly :) Why woudl this be useful ? Pushing and popping entire working register array takes plenty of cycles - sometiems it takes to long. If user could instruct the compiler not to push&pop registers that aren't used in interrupt handler, valuable cycles would be saved.

Something along the lines of {$MASK W9, W11, W12} would instruct the compiler not to generate push/pop pairs for registers W9, W11 and W12.

2: Add the option to implement interrupt handlers solely in assembly (short of RETFIE, of course). This is directly related to my first suggestion; if none of the registers are to be saved this would allow interrupt handler to contain only assembly code, allowing more efficient interrupt handlers for time-critical applications.

Posted: 30 Dec 2007 17:38
by jpc
In the last version of the pic-compiler DisableContextSaving was introduced allowing for similar improvements on PIC , i can imagine this to be implemented in the next dsPIC compilers too.

Re: Interrupt handling

Posted: 30 Dec 2007 19:02
by yo2lio
faramir wrote:Pushing and popping entire working register array takes plenty of cycles - sometiems it takes to long ...
It's too much for you 17 cycles for saving and 17 cycles for restore all working registers ?

Re: Interrupt handling

Posted: 08 Jan 2008 13:48
by faramir
yo2lio wrote:
faramir wrote:Pushing and popping entire working register array takes plenty of cycles - sometiems it takes to long ...
It's too much for you 17 cycles for saving and 17 cycles for restore all working registers ?
Yep, way too much; at maximum speed of 30 MIPS and with 1 msps A/D conversion this doesn't leave any room for immediate data processing whereas adjustable context switch would leave 10-20 cycles, restoring only those registers that actually get clobbered in the ISR. Not only that, it would also leave some spare cycles for the main loop ...