What to save in #INT_GLOBAL

RLScott · Joined: 10 Jul 2007 Posts: 465

I have used #INT_GLOBAL many times, but the ISR was always fairly simple so the stuff that gets saved and restored by RETFIE,FAST has been enough. Now I have an ISR that accesses an array of int32. The processor is a 18F24K22 so the built-in multiply is used to multiply the index by 4. This means saving PRODH and PRODL. The array access also uses FSR0 as it does arithmetic on an array element, so FSR0H,FSR0H also must be saved. I thought I was home free but the ISR was still interfering with the main program. Examining the disassembly I saw that the compiler is using file registers 0, 1, 2, and 3 as scratch registers (which my main program is also using). So I now am saving 0, 1, 2, 3. Now my main program seems to be running OK. But this leads me to wonder if there isn't some more systematic way of knowing what needs to be saved. What if the compiler decided to use FSR1? Or more scratch registers? I don't feel comfortable scouring the disassembly looking for possible conflicts. I know that the CCS constructed ISR saves everything it needs to save, but I want to do some things that coordinate several interrupts and service them in a known controllable order, so I really want to stick with #INT_GLOBAL. So what is the best practice in using #INT_GLOBAL? The manual just says to use extreme caution since the compiler won't be saving anything for you, but I did not see any guidance to help determine exactly what needs to be saved.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

No.

I've talked about this in the past. Only way seems to be to generate the code, and look at the assembler. What would be really 'nice', would be if there was some form of compiler option to tell you what registers a function uses. This of course (ideally) would be used by CCS to reduce the default register saving, so they would then only save the registers actually used by the functions in the interrupt handler. However they don't do anything so nice/sophisticated, so one is stuck with looking at the assembler....
A lot of things are common though.

Best Wishes

RLScott · Joined: 10 Jul 2007 Posts: 465

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

I think memcpy, uses FSR1 if I remember correctly, and a couple of the commands in the USB handlers.
TBLPTR, for EEPROM accesses.
If you have the IDE, you can change the scratch assignment. - Memory, C scratch RAM. If you use the option to compile separately and link, you can make your main program use a different area to the interrupt handler.

Best Wishes