 |
 |
View previous topic :: View next topic |
Author |
Message |
PointOnePA
Joined: 21 Oct 2018 Posts: 4
|
Hex Decompile - TABLAT Register Interrupt Push/Pop question |
Posted: Sun Oct 21, 2018 9:48 am |
|
|
I'm trying to recreate the build environment for an OLD application using the CCS PCH V4.112 compiler on an PIC18F2420 target . I'm doing this to document that I have the source code to match an old .hex file, as a starting point for my code changes. My problem is that the .hex file from MY BUILD contains the following EXTRA PUSH/POP registers in the interrupt.
Code: |
29 0038 CFF5 MOVFF 0xff5, 0x15 ; TABLAT
30 003A F015 NOP
31 003C CFF6 MOVFF 0xff6, 0x16 ; TBLPTRL
32 003E F016 NOP
33 0040 CFF7 MOVFF 0xff7, 0x17 ; TBLPTRH
34 0042 F017 NOP
.
.
.
88 00AE C015 MOVFF 0x15, 0xff5 ; TABLAT
89 00B0 FFF5 NOP
90 00B2 C016 MOVFF 0x16, 0xff6 ; TBLPTRL
91 00B4 FFF6 NOP
92 00B6 C017 MOVFF 0x17, 0xff7 ; TBLPTRH
93 00B8 FFF7 NOP
|
These statements are not in the OLD .hex file, as compared by importing the .hex file into MPLAB to decompile it. So MY RETFIE is at accress 00C4 and the OLD .hex RETFIE is at 00AC.
So my questions are:
1) Are these registers added to the push/pop list automatically, based on some register usage calculation by the compiler;
or
2) Are these registers optionally added to the push/pop list, and there is some compiler control directive for removing these from that list.
3) I see that there are optimization levels 0-9, but I haven't seen any details as to what these different levels of optimization do. I currently have the default #opt 9.
I believe that I'm using the correct compiler version, V4.112, but I'm wondering if a previous version of the compiler handled interrupt push differently and perhaps I have the wrong compiler. This version is too old to see a list of the changes on the CCSinfo website.
I've read about the #separate option, but I don't have an example on how to use it for TABLAT.
Any suggestions are be appreciated. |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 19732
|
|
Posted: Sun Oct 21, 2018 10:30 am |
|
|
None of these instructions are pushes or pops....
They are simply saving/restoring the table pointer registers to scratch.
Honestly, if you need to match the old code, the only way to do it, would be to use #INT_GLOBAL, and manually save/restore the registers to match the old code (and poll the interrupt involved). However I would have expected the table pointers to have been saved, otherwise there will be problems as these are used anywhere.
Optimisation has no effect on the registers being saved. All temporary registers are always saved unless you use INT_GLOBAL and do it yourself.
Are you sure the hex was built for the same chip, and with this compiler?. A quick check shows that a basic interrupt handler built on 4.114, does exactly the same save/restore of these three registers. |
|
 |
PointOnePA
Joined: 21 Oct 2018 Posts: 4
|
|
Posted: Sun Oct 21, 2018 12:00 pm |
|
|
Ttelmah, thanks for the information and correction on push/pop. I was hoping that there might be a compiler directive to disable this. The documentation that I have and some build files from the same era, including a list file, indicate the compiler was:
CCS PCH C Compiler, Version 4.112, 12345678 15-Oct-10 14:12
The second to last lines of the .HEX file I'm trying to match states:
";PIC18F2420", and the last line indicates CREATED="18-Dec-09".
so I'm sure that I have the right target, but the compiler could be earlier than 4.112. You mentioned "a quick check shows that ....on 4.114". Where did you find that information, or is that from software you have installed? I'm just wonder if I can look at compilers prior to 4.112 to see if they worked the same way.
If I have to, I can replace the existing interrupt dispatcher with custom code to avoid having these table points written to scratch, but if I can do it with the existing V4.112 compiler directives, that would be preferred. |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 19732
|
|
Posted: Mon Oct 22, 2018 6:18 am |
|
|
4.112, also saves these registers.
It has to. Otherwise anything using table addressing, will result in register corruption.
Code: |
//Interrupt handler for a timer interrupt compiled with 4.112
CCS PCH C Compiler, Version 4.112, 93505794 22-Oct-18 13:08
Filename: C:\Program Files\PICC\testmplab\main2420.lst
ROM used: 246 bytes (2%)
Largest free fragment is 16134
RAM used: 25 (3%) at main() level
25 (3%) worst case
Stack: 1 worst case (0 in main + 1 for interrupts)
*
0000: GOTO 00B6
*
0008: MOVWF 04
000A: MOVFF STATUS,05
000E: MOVFF BSR,06
0012: MOVLB 0
0014: MOVFF FSR0L,0C
0018: MOVFF FSR0H,07
001C: MOVFF FSR1L,08
0020: MOVFF FSR1H,09
0024: MOVFF FSR2L,0A
0028: MOVFF FSR2H,0B
002C: MOVFF PRODL,12
0030: MOVFF PRODH,13
0034: MOVFF PCLATH,14
0038: MOVFF TABLAT,15
003C: MOVFF TBLPTRL,16
0040: MOVFF TBLPTRH,17
0044: MOVFF 00,0E
0048: MOVFF 01,0F
004C: MOVFF 02,10
0050: MOVFF 03,11
0054: BTFSS PIE1.TMR1IE
0056: GOTO 0060
005A: BTFSC PIR1.TMR1IF
005C: GOTO 00AE
0060: MOVFF 0E,00
0064: MOVFF 0F,01
0068: MOVFF 10,02
006C: MOVFF 11,03
0070: MOVFF 0C,FSR0L
0074: MOVFF 07,FSR0H
0078: BSF 07.7
007A: MOVFF 08,FSR1L
007E: MOVFF 09,FSR1H
0082: MOVFF 0A,FSR2L
0086: MOVFF 0B,FSR2H
008A: MOVFF 12,PRODL
008E: MOVFF 13,PRODH
0092: MOVFF 14,PCLATH
0096: MOVFF 15,TABLAT
009A: MOVFF 16,TBLPTRL
009E: MOVFF 17,TBLPTRH
00A2: MOVF 04,W
00A4: MOVFF 06,BSR
00A8: MOVFF 05,STATUS
00AC: RETFIE 0
|
I just pulled the versions out of my archives. I always keep old compilers just for this reason. Trying to compile old code with a new compiler is sure to result in changes.
As you can see though, my code contains those saves and restores, but ends at 0xAC. I think there is something else different.
I just compiled exactly the same code with 5.081, and it gives the identical interrupt handler.
You don't say what your current compiler version is?.
There is a setting you can apply which is meant to 'undo' some of the changes that occurred with the V5 compiler;
#device CCS4
This applied to many early versions of the V5 compiler, where there was a change to the order the registers saved. |
|
 |
PointOnePA
Joined: 21 Oct 2018 Posts: 4
|
|
Posted: Mon Oct 22, 2018 6:30 am |
|
|
Ttelmah, thanks again for the suggestions.
I did some research using archive.org, following suggestions from forum posts, and found that version 4.112 was not used to create this .hex file because it was not available until Sep 19, 2010, so could not have been used to create this 18-Dec-09 .hex file. So I'm going to look at an earlier compiler to see if it resolves the problem. I agree with you that the table registers need to be saved to avoid corruption, but I can see that they are not being saved in this 2009 .hex file that I'm attempt to recreate. The only reason I want to recreate the file is to validate the C source as a known starting place. Once I know that source, I can update the compiler to a more reasonable version.
Code: |
-----------Compiler Version Dates Using Archive.org-----------------
Date Current Version
Feb 23, 2009 4.086
Nov 2, 2009 4.099
Jan 26, 2010 4.104
Sep 19, 2010 4.112
Dec 14, 2010 4.115
Oct 14, 2011 4.125
|
|
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 19732
|
|
Posted: Mon Oct 22, 2018 7:38 am |
|
|
4.099, produces a smaller interrupt handler, without those specific saves. I'd guess the code itself does not use those registers in the same way.
If you want to build the code, contact CCS. They have an option in their download page for 'old compiler versions'. They should be possibly able to do 4.099 for you. |
|
 |
PointOnePA
Joined: 21 Oct 2018 Posts: 4
|
|
Posted: Mon Oct 22, 2018 8:32 am |
|
|
Ttelmah, thanks again for the comments.
CCS Tech support has been great. They set me up with V4.099 and I'm checking it out now. I'll follow up with a summary once I've completed this process.
This Forum ROCKS! |
|
 |
|
|
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
|