| View previous topic :: View next topic |
| Author |
Message |
Josep Robert
Joined: 27 Mar 2018
Posts: 25
|
| Compiler command line v5.098 problem? |
 Posted: Mon Dec 28, 2020 1:33 am |
 |
|
Today I've received the last ccs command line compiler version v5.098.
I’ve recompiled some of my projects for PIC18LF47K40 and found that the used ROM increases a 6%-7%.
Looking at .lst files I realized that there are a lot of these differences:
| Code: |
ccs 5.097 ccs 5.098
BNZ xxxx <---> BTFSS STATUS.2
GOTO yyyy
2 bytes <---> 6 bytes
|
Is this a malfunction? Is this a bad improvement?
| Code: |
--------------------------------------------
CCS PCH C Compiler, Version 5.097, 53681 21-dic.-20 09:49
Filename: C:\Users\...\production\main.lst
ROM used: 111890 bytes (85%) <<<<<<<<<<<<<<<<
Largest free fragment is 9216
RAM used: 3294 (40%) at main() level
3509 (43%) worst case
Stack used: 7 locations (4 in main + 3 for interrupts)
Stack size: 31
--------------------------------------------
|
| Code: |
--------------------------------------------
CCS PCH C Compiler, Version 5.098, 53681 28-dic.-20 07:43
Filename: C:\Users\...\production\main.lst
ROM used: 120320 bytes (92%) <<<<<<<<<<<<<<<<
Largest free fragment is 6144
RAM used: 3294 (40%) at main() level
3509 (43%) worst case
Stack used: 7 locations (4 in main + 3 for interrupts)
Stack size: 31
*
--------------------------------------------
|
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Mon Dec 28, 2020 1:39 am |
|
|
The difference is that the original branch will only support a 'local' jump.
So only to an address within -128 to +127 of the current instruction.
The new code supports a jump to anywhere in the ROM.
Either something in the code has moved, requiring a long jump to be used,
or they have decided to implement the long jump because they have had
issues with things being too far away. |
|
|
Josep Robert
Joined: 27 Mar 2018
Posts: 25
|
|
| Posted: Mon Dec 28, 2020 2:36 am |
|
|
Thanks Ttelmah
The code is 100.00% the same. The only difference is the compiler version used.
I've have the two versions installed; with the previous version a 7% less flash is used. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Mon Dec 28, 2020 5:39 am |
|
|
One possible reason for the increased codespace is that the new compiler's algorithm for putting code into the PIC is different than previous version. Your program uses 85% of flash. quite large, I assume with lots of functions. The compiler will somehow figure out how to put the code for a function into one bank of memory. This can get 'tricky' when there's lots of program to consider.
Think of functions as paragraphs in a book. They have to be complete and all of it's words have to be on the same page, so the compiler 'shuffles' them where ever it can and at the same time trying to comapct the code so each 'page' of flash is as full as possible.
As a side note.at 85% usage, in the near future, you may need to reconsider coding style when adding more features and functions to your program. You may find out that you've run out of space....
Jay |
|
|
jaka
Joined: 04 May 2014
Posts: 35
Location: Finland
|
|
| Posted: Mon Dec 28, 2020 7:02 am |
|
|
I am seeing similar things happening. All branches on 5.097 are changed to gotos on 5.098. And my program is small. ROM usage increased from 1178 bytes to 1390, that's 18% increase. This in on 18F26K83, so I am using only 2% of ROM.
It's not that I am worried about running out of ROM on this project, but it would be nice to know the reason for this change. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Mon Dec 28, 2020 7:24 am |
|
|
As Mr. T pointed out, the compiler now supports 'jumps anywhere in ROM', so I assume even those 'local' jumps are now using the newer,larger code.
Now if this becomes an 'issue', either in space or time, you can always try recoding inline or ASM to use 'local' jump coding.You could ask CCS to modify the compiler so that 'If the jump <126 locations, use 'local jump' else use 'long jump' code.
Or, simply use and older 'prelongjump' version of the compiler.
There are several possible solutions. Which you choose depends on your needs. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Mon Dec 28, 2020 7:43 am |
|
|
It is quite interesting. They seem to be avoiding the 'relative' instructions
everywhere. RCALL's are changed to CALLs, and the relative jumps have
switched to full 16bit jumps.
Now potentially this should allow them to actually pack things better, but
comes at the cost of using more space for these instructions (and more
time - a relative jump/call is one instruction time faster than he full
versions). However there seems to be little sign that there have been any
optimisation improvements in the packing, so it does rather seem a step
backwards.
Does anyone know if any of the newest chips have an erratum on relative
jumps/calls?. If so, they may have been coding to handle this, and it has
got 'accidentally' included into the normal code. It is not mentioned in the
'recent changes'.
I think I would raise this with CCS. It seems to be a step away from good
optimisation. 
It is doing the same on PIC16's as well. However no sign of any change on
PIC24/33 chips (code seems identical to the old compiler on these). |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Mon Dec 28, 2020 8:32 am |
|
|
It might be part of a 'universal' philosophy.
Trying to get the compiler to 'be all - for all' PICs.
While timing and space were a true concern,say with a PIC16C84...it's not really a problem with a PIC18F46K22 running at 64MHz.....
Reminds me of the 'bloatware' that Windoze has become.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Mon Dec 28, 2020 11:46 am |
|
|
My suspicion is that possibly a stage of the build has become omitted.
If you think about it deciding if you 'can' use a relative jump is quite
complex to do. The standard approach would be to build completely with
the full jumps, and then at each one, test if the target is inside the relative
range, and if so substitute a relative jump. You may 'miss' the occasional
jump where the target is out of range, and comes into range after some
other jumps are substituted, but should get 99% of the locations where
a relative jump/call can be used. So I'd almost suspect this is the
approach used by CCS, and somehow the substitution scan is being
omitted. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Dec 28, 2020 4:18 pm |
|
|
I sent an email to CCS support regarding this problem, about 1 hour ago.
I pointed them to this thread and gave them a small test program that
generates GOTO's with vs. 5.098 but BRA's with vs. 5.097.
Test program:
| Code: |
#include <18F46K22.h>
#use delay(internal=4M)
#use rs232(baud=9600, UART1, ERRORS)
//---------------
void func3()
{
int8 i;
i = 0xAA;
printf("i = %u", i);
}
//---------------
void func2()
{
int8 i;
i = 0xAA;
func3();
}
//---------------
void func1()
{
int8 temp;
temp = 0x55;
func2();
}
//======================
void main(void)
{
func1();
while(TRUE);
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Tue Dec 29, 2020 12:42 am |
|
|
| Well done PCM. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Wed Dec 30, 2020 5:06 am |
|
|
Though I reported that 5.098, does not have this fault with the PIC24/33
chips, it appears it has a lot of other new problems. Code that was working
fine before now does not run, and it is behaving as if it is not initialising
variables correctly. I have variables for a state machine, and the display
format, and running on 5.098, it wakes up with these containing unexpected
values, though both are set to initial values when declared.
So as it stands, I'd suggest that people might well be advised to go
back to 5.097. 5.098, seems to have some very odd issues.... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 30, 2020 3:23 pm |
|
|
CCS says they have fixed the problem and will release the updated
version soon. |
|
|
Torello
Joined: 29 Sep 2006
Posts: 120
|
|
| Posted: Wed Jan 06, 2021 3:57 am |
|
|
Hi,
The ROM use gain v5097 to v5098 is -dramatically-!
I'm using a Pic18lf8546 on a on going project for years. Rom is pretty full and I'm really coding to save Rom resources. In version 5097 I am at 87%. Compiling the same code on with version 5098...
97% percent
Crap! All my effort demolished. Can barely add anything any more. Looks like stuck to version 5097.
I've contacted CCS to explain.
_________________
Regards, Edwin. PCWHD v5.114 |
|
|
jaka
Joined: 04 May 2014
Posts: 35
Location: Finland
|
|
| Posted: Thu Jan 07, 2021 12:10 am |
|
|
5.099 is just released. I tested it, and I am getting exactly same .hex output as with 5.097 on my current project.
So it seems that the optimization bug appeared in 5.098 is fixed. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
