[dcbrown]

That was the specific feature I was thinking about. I *don't* like the fact that all of the compiler managed resources are saved unless you do a nosave to exclude them... kinda of the opposite of 2.4 where you had to specify them in order to save them. I also really wish there was a "use a return instead of a RETIE" option - that would really help. But I do like that a different .tmpdata section is created for the interrupt service routines.

I'll give this some thought, because it gets confusing since it deals with SFRs of the PIC and how the compiler uses them (and when).

Honestly, other than reading the docs I haven't used the 3.0+ compiler yet. I'm hoping to get it installed on my laptop this weekend.


I have played a lot of "games" with context in V2.4. One is to setup the main interrupt service routine with minimal context save: just WREG, BSR, STATUS, FSR0 and PRODL/H. The FSR0 is used by the compiler to hold computed ram addresses - like for data_array[var]. The PRODH/L registers can be used for bit shifts, some data array index calculations and some other general stuff. This covers 80%-90% of the interrupt dispatcher and drivers.

For any driver that needs more than these, I just declare that driver as an interrupt service routine and tell it what additional data or sections or h/w registers to save. But the downside was it would always re-save WREG, BSR, and STATUS on me. With V3.0 I can now avoid that resave. And yeah, I had to play some more games to get this to work (the first RETIE turns interrupts back on). But it can be a big win in that the majority of light weight drivers don't pay the price of saving a large context that only a few certain drivers needed. The new .tmpdata actually makes this strategy no longer as easy to do (there are always ways - just not as easy anymore).

Anyway, context save/restores is a longish post but will try. I'll start off with what the C18 manual says about latency. Latency more than just speed is what matters in real-time systems. The latency of an interrupt service routine is broken down into the following chunks:
1. Processor redirecting execution to the interrupt vector (.3-.4usec)
2. Interrupt vector execution (.4 usec)
3. Interrupt service routine preamble (context save, variable)
4. Interrupt dispatch (locate the interrupt to be serviced) (~.2-.3 usec per interrupt to be checked)
5. "Driver" for that interrupt (varies, but usually <10usec)
6. Interrupt service routine epilogue (context save)
7. RETIE, return and turn interrupts back on

More later. I'll need to find some specific examples of C lines using the different compiler managed resources to show why they need to be saved. Sometimes its not obvious what gets used.