Hope it's OK to butt in on this
The more the merrier!
Firstly, am I right in thinking that is a bit of a pointless usage of the command as it saves FSR0 and FSR1 anyway when you call Save(0)?
If you add on 'FSR0, FSR1' to a 'Save(0)' it's smart enough to skip saving them a second time so it doesn't hurt anything, but they're already covered by specifying '0'. Note that '0' doesn't save FSR2, but the compiler doesn't normally use that one (although some libraries might).
Secondly, you say it saves some system variables. Where in the asm code does this happen?
It's right there in front of you (ok, it's clear as mud)...
Code: Select all
ISR_ONINT_854
MOVLB 0
MOVFF _FSR0L#M0_U16H,F231_U16H // save FSR0
MOVFF _FSR0L#M0_U16,F231_U16
MOVFF _FSR1L#M0_U16H,F233_U16H // save FSR1
MOVFF _FSR1L#M0_U16,F233_U16
LFSR 0,F235_U200 // load FSR0 with the address of the save block
CLRF FSR1L,0 // load FSR1 with the starting address of the system vars (0)
CLRF FSR1H,0
MOVLW 25 // set count=25 (sizeof system var block)
MOVFF POSTINC1,POSTINC0 // copy *FSR1++ -> *FSR0++
DECFSZ WREG,1,0 // decr count
BRA $ - 6
MOVFF PRODL,F260_U08 // save PROD (L and H)
MOVFF PRODH,F261_U08
The code appears to be working but I also don't appear to use any SB_ variables in my ISR, although I do use some Fxxx variables.
If you're sure you don't have any calls in the ISR that may end up using a SB_ variable then you'd be safe removing the '0' and just using 'save(FSR0, FSR1, PRODL, PRODH)'. You should specify saving each of the eight-bit PROD regs individually since right now most of the device files have PROD defined as a single 8-bit register. You could also add a 'dim PROD as PRODL.asword' to change that.
The existence of Fxxxx variables means that the ISR is using some of the stack frame and that can be a red flag that something might need protecting, but not always. If the code that generates the frame variables is directly visible in the ISR then the compiler generally takes note of this and doesn't reuse them, effectively making them static. It's also possible that the Fxxxx variable is just part of the context save itself (like in the above code saving FSR), so that's ok too. It's usually only if you have subroutines involved that things get murky.
One thing you can do to help you decipher what the Fxxxx variables are for is to add
to your main program. That will add some decoration to the Fxxx name if it's a declared variable...
Code: Select all
#option _showvar = true
sub s()
dim a, b, c as word
<snip>
A_F41_U16 EQU 66
A_F41_U16H EQU 67
B_F43_U16 EQU 68
B_F43_U16H EQU 69
C_F45_U16 EQU 70
C_F45_U16H EQU 71
F47_U08 EQU 72
F48_U08 EQU 73
F49_U08 EQU 74
You can see that the Fxxxx names for A, B, and C are prefixed by the identifier, making them easier to find. The remaining Fxxx ones are created by the compiler. In the above, the EQU is specifying the memory address in RAM. If two variables are sharing the same locations, this is where you'll find it... they'll have the same EQU location.
Another way to find out what's used by a block of code is to turn the block into a subroutine on purpose, and add the name of the subroutine to the save list. That'll tell the compiler to go look at the code and determine what it might need to save.