interrupt handlers the way god intended

[notzed]

[timpart]

I fully agree assembler is currently best for writing interrupt handlers, since .

One irritation, even with assembler, is that the chip doesn't have any registers reserved for ISR use. (Some chips have a shadow set which come into play.) I've been mulling over making a request for a compiler option to tell the compiler not to use registers R24 to R27. (There is already one to tell it not to use R32 to R63 for use with future versions of the chip with only 32 registers.) If we had some registers we knew the compiler wouldn't touch in ordinary routines we could use them as scratch registers in an ISR without having to save and restore them first, speeding things up a little.

I'd turn off the option by default, since not everyone would need it. (The standard libraries would have to be compiled with the option on though.) Any thoughts on this suggestion?

Tim

[notzed]

It's a bit of a bummer that even status isn't shadowed although you'd have to save any shadowed registers for nested interrupts anyway.

Do you have a case where the 4 extra instructions to save/restore 4 regs by writing to/reading from local memory will make a practical impact? Compared to the mesh latency?

You could borrow the 4 'constant' registers 28-31 to test whether it makes enough of a difference to matter. Only r28 has a reserved use at the moment as a PIC base pointer which probably isn't used by anyone yet, pity r15 isn't PC for that tho.

Slightly related: last year I tried adjusting the abi in a custom build of the compiler by changing r0-r7 to arg/scratch, r8-15 saved. But i didn't really have enough code to test to determine if it improved anything by being able to use short instructions more often in leaf functions and with argument construction. And sp forced everything to 32-bits anyway (maybe r7=sp would help).

[timpart]

[notzed]

[notzed]

[notzed]

Confirmed it should be 8-byte aligned:

viewtopic.php?f=23&t=1064&p=6740#p6722