 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Very serious bug - code ignored in #INT_GLOBAL |
 Posted: Mon Sep 28, 2015 9:13 am |
 |
|
The following block of code in an #INT_GLOBAL routine fails to compile anything for the code that restores scratch0:
| Code: |
.................... if(PIR1.TMR1IF)
00FE: BTFSS F9E.0
0100: BRA 0112
.................... {
.................... PIR1.TMR1IF = 0;
0102: BCF F9E.0
.................... scratch0 = Tmr1Overflow+1;
0104: MOVLW 01
0106: MOVLB 1
0108: ADDWF xCC,W
010A: MOVWF 00
.................... Tmr1Overflow = scratch0;
010C: MOVFF 00,1CC
0110: MOVLB 0
.................... }
.................... scratch0 = savedScratch0;
.................... scratch1 = savedScratch1;
0112: MOVFF 43,01
.................... #asm
.................... RETFIE 1 ;..fast return restores registers
0116: RETFIE 1
.................... #endasm
.................... }
|
The use of scratch0 was devised to illustrate a minimal code failure and not exactly what led me to investigate this. The PIC is a 18F24K22 and the compiler is the command-line PCH Version 4.128 running from MPLAB. The relevant definitions are:
| Code: | #byte scratch0=0
#byte scratch1=1 |
since these are the scratch locations used by the compiler in some complex calculations.
So far, by trying variations on this theme, here is what I have found:
1. The exact same block of code compiles correctly when placed in an ordinary function (not a #INT_GLOBAL).
2. The restore of scratch0 compiles fine if the previous code is not an "if" block.
3. The restore of scratch0 compiles fine if I make seemingly insignificant changes to the previous "if" block, like replacing the "if" condition by a test of a general RAM variable and not a bit test of a SFR. (I think it has to do with bank selection.)
4. If I switch scratch0 and scratch1, it is the scratch1 code that compiles to nothing. In other words, the first such assignment compiles to nothing.
5. If I redefine scracth0 to any address besides 0, 1, 2, 3, it compiles fine. The compiler is apparently making a special effort to recognize its own scratch locations.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19467
|
|
| Posted: Mon Sep 28, 2015 1:09 pm |
|
|
4.128, is rather old.
There were quite a few problems with some compilers round this time.
I do remember something similar being discussed. Even the behaviour with the action depending on what was in front, is familiar. If I remember a syntax was found to avoid the problem but I can't remember what it was. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Sep 28, 2015 1:33 pm |
|
|
| Ttelmah wrote: | 4.128, is rather old.
There were quite a few problems with some compilers round this time.
I do remember something similar being discussed. Even the behaviour with the action depending on what was in front, is familiar. If I remember a syntax was found to avoid the problem but I can't remember what it was. |
My workaround is to restore FSR0 first and then restore the scratch registers. Then, for some reason, all statements compile correctly.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
