 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Optimization depends on lexical presentation of source! |
 Posted: Wed Aug 07, 2013 8:19 pm |
 |
|
Here is a strange thing I just encountered with the PCH compiler. When this block of code takes two lines in the source file, I get:
| Code: | 16: if(bit_test(abc,6))
0068 AC37 BTFSS 0x37, 0x6, ACCESS
006A D001 BRA 0x6e
17: LATC.RC4 = 1;
006C 888B BSF 0xf8b, 0x4, ACCESS |
But if I compile the exact same code presented on one line, I get:
| Code: | 13: if(bit_test(abc,6)) LATC.RC4 = 1;
0064 BC37 BTFSC 0x37, 0x6, ACCESS
0066 888B BSF 0xf8b, 0x4, ACCESS |
Obviously I prefer the optimization in the second case. But isn't it strange that the only way to get that optimization is to write the code on one line?
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
 |
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Wed Aug 07, 2013 8:52 pm |
|
|
(cringe)
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Thu Aug 08, 2013 2:02 am |
|
|
Obviously, report it.
It is interesting, since it 'switches assumption', and decides there is going to be more than one instruction of code (which therefore requires the jump). Instead of actually working out how much code is involved, it is basing the assumption on the statement being on one line, as it's starting point.
Does the same over half a dozen compiler versions - I went back to 4.117, and up to 5.010.
Changing #OPT also has no effect on this.
Best Wishes |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
| Re: Optimization depends on lexical presentation of source! |
| Posted: Thu Aug 08, 2013 5:33 am |
|
|
| RLScott wrote: | Here is a strange thing I just encountered with the PCH compiler. When this block of code takes two lines in the source file, I get:
| Code: | 16: if(bit_test(abc,6))
0068 AC37 BTFSS 0x37, 0x6, ACCESS
006A D001 BRA 0x6e
17: LATC.RC4 = 1;
006C 888B BSF 0xf8b, 0x4, ACCESS |
But if I compile the exact same code presented on one line, I get:
| Code: | 13: if(bit_test(abc,6)) LATC.RC4 = 1;
0064 BC37 BTFSC 0x37, 0x6, ACCESS
0066 888B BSF 0xf8b, 0x4, ACCESS |
Obviously I prefer the optimization in the second case. But isn't it strange that the only way to get that optimization is to write the code on one line? |
Hmm, not all that strange if we consider what may be happening. It makes more sense if the compiler is working line by line with no look-ahead. It also makes sense if we consider some possible context you're left out of the example: else. If the code was:
| Code: |
if(bit_test(abc,6))
LATC.RC4 = 1;
else
LATC.RC4 = 0;
|
then the optimisation would not be possible. It would also not be possible if the code following the if compiled to more than one PIC instruction as the skip skips one, and only one, instruction.
To me, the code doesn't look like its being optimised after compilation, rather its being compiled using keyhole source optimisations on a line by basis: if the optimisation cannot be "seen" in the current source line, then its not done at all. This was fairly common optimisation behaviour some time ago, when "long view" optimisations, looking forward ahead over more than the current line to see what MIGHT be coming later, were not so practical as they are today. As such, I suspect this might be a hangover of some simple optimisation from early in the compiler's life.
I would question whether its even a "fault" of the compiler as such. One cycle or one program memory location here and there is not generally going to make all that much difference in the great scheme of things. Its certainly a quirk, but is it a fault? The code works either way, just not as fast in one version as the other. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: Optimization depends on lexical presentation of source! |
| Posted: Thu Aug 08, 2013 3:05 pm |
|
|
| RF_Developer wrote: |
I would question whether its even a "fault" of the compiler as such. One cycle or one program memory location here and there is not generally going to make all that much difference in the great scheme of things. Its certainly a quirk, but is it a fault? The code works either way, just not as fast in one version as the other. |
I have a bit-banged SPI (the SDO pin is needed for Async serial in my app) that I have implemented with an unrolled loop handling 16 iterations inline for speed. With the optimization I get 5 instruction cycles per bit. Without the optimization it is 6 instruction cycles per bit. That is 20% longer. On an app that is heavy with SPI activity, that is not something you want to casually throw away.
But I agree that it is not a serious fault, especially since the workaround is so easy. I would not bother changing the compiler. I would just document the way it works now and leave it at that.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Thu Aug 08, 2013 4:43 pm |
|
|
O M G !!!!!
i have"seen" this in other constructions of my own,
but it did not register !!!
since the code still worked.
but now i will work around it by my program construction
THANK YOU for pointing this out .
it is a kind of deep issue for CCS, neh ?? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Fri Aug 09, 2013 12:20 am |
|
|
Not really, though it should be fixed.
The number of occasions where a statement codes as a single instruction line, is tiny. Even just simple things will normally involve bank switching, so an extra instruction is needed, and this won't then change.
I think RF_developer has put his finger on what is happening perfectly. The compiler does not at this level at least perform any assembler optimisation but instead uses different assumptions based on the source code. It does imply that a quick experiment in layout, may change things in quite few places. It is rather like the 'old one' with switch statements, where having a 'default' prevents a jump table from being used. This still applies with the latest compilers, and just means that you have to fractionally 'switch' programming styles, and get into the habit of testing for the default conditions yourself, and then having a switch statement without a default....
Best Wishes |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9174
Location: Greensville,Ontario
|
|
| Posted: Fri Aug 09, 2013 5:31 am |
|
|
Like a road with a fork in it...which way to go ?
It does point out the complexities of writing a compiler! Trying to 'second guess' what might happen next, how to omptimize,etc.
It also shows why knowing assembler can be very,very helpful.Dumping the listing out and seeing what 'it' does, allows a good programmer to 'fine tune' code.
Unlike a PC where you can just get a faster CPU,PICs have a top end speed, so 'digging into the details' is essential for getting the best performance out of them.
jay |
|
|
|
|
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
