....I discovered you do an ASM Interrupt, part way through the ISR jump out of ASM, add some PBP, then jump back into ASM to RETFIE
In the end your compiled PBP statements are ASM too so yes, in theory, you can do that but remember that the PBP statements you use in that ISR might use the same system variables as your main routine and can therefor corrupt those values for whatever it was your main program was doing when it got interrupted.

DT-Ints, as I'm sure you know, handles this by reserving space for, saving on ISR entry and restoring on ISR exit all these system variables. It's somewhat clever in that it "only" saves/restores system variables that the program uses but it does so no matter if the code in the ISR would affect those variables or not.

What I've done on occasions is to write my ISR in PBP but treat it as an assembly type interrupt and then, by looking at the generated .lst file, figure out which system variables my PBP ISR code is actually affecting and then add save/restore code for those ONLY. It works but you need to be very methodical and follow every library call and it's obviously extremely easy to mess up since adding a single line of code to ISR (or even chaning one) could effectively ruin your day.

I'd like to see it built into the compiler with enough intelligense to analyze the code in the ISR and determine exaclty which variables are actually needed to be saved/restored. I mean, sure the main program might use variable T1,T2,T3 but if the code in the ISR only uses T2 then why waste time and space on saving/restoring all three? Some sort of report would be a nice touch so one can figure out the expected latency - which would then obviously vary depending on code complexity of the ISR.

It would be interesting to know how the compiler(s) from MikroE is handling this, anyone in the know?

/Henrik.