We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm a bit curious as to why this bit of code wasn't AS optimized as it would normally be. I have written compilers, so I am not clueless it's just strange the optimizer didn't optimize out some of this code. This code becomes
ADCON1 = chan->constants.location_info.con1 & 0x70; ADMUX = chan->constants.location_info.mux; ADCON0 = chan->constants.type_info.con0; OCH = chan->a2d.och; OCM = chan->a2d.ocm; OCL = chan->a2d.ocl; GCH = chan->a2d.gch; GCM = chan->a2d.gcm; GCL = chan->a2d.gcl;
this code
0010 L?0038: 0010 L?0039: 0010 F582 MOV DPL,A 0012 E4 CLR A 0013 3E ADDC A,R6 0014 F583 MOV DPH,A 0016 E0 MOVX A,@DPTR 0017 22 RET 0000 8F82 MOV DPL,R7 0002 8E83 MOV DPH,R6 0004 A3 INC DPTR 0005 A3 INC DPTR 0006 E0 MOVX A,@DPTR 0007 5470 ANL A,#070H 0009 F5DD MOV ADCON1,A ; SOURCE LINE # 279 000B 8F82 MOV DPL,R7 000D 8E83 MOV DPH,R6 000F E0 MOVX A,@DPTR 0010 F5D7 MOV ADMUX,A ; SOURCE LINE # 282 0012 EF MOV A,R7 0013 2404 ADD A,#04H 0015 120000 R LCALL L?0038 0018 F5DC MOV ADCON0,A ; SOURCE LINE # 286 001A EF MOV A,R7 001B 2417 ADD A,#017H 001D 120000 R LCALL L?0038 0020 F5D3 MOV OCH,A ; SOURCE LINE # 287 0022 EF MOV A,R7 0023 2418 ADD A,#018H 0025 120000 R LCALL L?0039 0028 F5D2 MOV OCM,A ; SOURCE LINE # 288 002A EF MOV A,R7 002B 2419 ADD A,#019H 002D 120000 R LCALL L?0039 0030 F5D1 MOV OCL,A ; SOURCE LINE # 290 0032 EF MOV A,R7 0033 241A ADD A,#01AH 0035 120000 R LCALL L?0039 0038 F5D6 MOV GCH,A ; SOURCE LINE # 291 003A EF MOV A,R7 003B 241B ADD A,#01BH 003D 120000 R LCALL L?0039 0040 F5D5 MOV GCM,A ; SOURCE LINE # 292 0042 EF MOV A,R7 0043 241C ADD A,#01CH 0045 120000 R LCALL L?0039 0048 F5D4 MOV GCL,A
First all the information is references from a pointer. All variable data access is sequential from said pointer. Why isn't it optimizing out the ADD A, #XXX into INC DPTR? It has done this a number of other places in the code. Why not here?
Do I have the settings wrong or something? Do I need to arrange the code differently?
This is embedded into an ISR could that be the reason (that wouldn't make sense however ... )
If anyone can let me know if I need to do something different.
Stephen
Yes knowingly having looked at the back end optimization of GCC was an eyefull. Generally the optimization starts with twiddling redundant stuff out. I suppose if it's done in a single pass that could lead to reductions (this is more toward algebraic simplification type analysis). I was just curious if it would recognize that it was adding sequential offsets. IE that P (instance result of REFERENCE MEMBER (N)) was indeed the prior computations P' + 1 that seems to be the challenge. The optimization doesn't make sense to human eyes because a human tends to use different logic than a programmatic approach would. I suppose changing the symbolic representation by twiddling code would work (heh). Unfortunately the stumbling block I suspect for the optimizer is the fact I am using members of a structure instead of a pointer to a series of equally sized variables (IE byte sized entities). The optimizer has to pass over several layers of symbol sets and optimizations before it can emit code. Unfortunately what optimization to apply each time is not as easy.
I thought I would see if there was some way to get the optimizer to recognize a sequence of incremental addresses like I have here. Would make the ISR time shorter and less code. However I don't want to end up with code that doesn't perform the same function.
Thanks for your comments gives me a little more confidence that I recognize the limitation. Unfortunately to keep code clarity recasting a pointer is a bad idea. (that would be the easiest way to make the code optimizer recognize sequential addresses)
I am surprised that it doesn't reduce the offset reference set more but at the same time I am not. If it were a global variable and not a pointer it would be optimized I suspect. It's the pointer and reference from a pointer that makes it difficult for the optimizer.
I thought I would see if there was some way to get the optimizer to recognize a sequence of incremental addresses like I have here. Would make the ISR time shorter and less code. However I don't want to end up with code that doesn't perform the same function. I have a place where I have to do a MAJOR sequential to sequential move. My derivative does not have 2 DPTRS which Keil AFAIK do use when available, so I wrote it in assembler (ultimate optimizer [if you know what you are doing]) and gained more than ten times performance improvement and the code "does perform the same function"
Unfortunately to keep code clarity recasting a pointer is a bad idea. please elaborate I do not see why
Erik
More interesting code checking. This really shows more what is going on. The code really is very simple and straight forward and yet ...
Compiler settings:
OPTIMIZE (9,SIZE) BROWSE NOINTPROMOTE INCDIR(.\headers) DEBUG OBJECTEXTEND CODE LISTINCLUDE SYMBOLS PRINT(.\object\list_map\*.lst) TABS (3)
C Code
void print_hex4(uint8_t xdata * dat) { print_hex(*dat++); //dat++; print_hex(*dat++); //dat++; print_hex(*dat++); //dat++; print_hex(*dat); }
Output Listing
; FUNCTION _print_hex4 (BEGIN) ; SOURCE LINE # 175 0000 8E00 R MOV dat,R6 0002 8F00 R MOV dat+01H,R7 ; SOURCE LINE # 176 ; SOURCE LINE # 177 0004 0500 R INC dat+01H 0006 E500 R MOV A,dat+01H 0008 7002 JNZ ?C0051 000A 0500 R INC dat 000C ?C0051: 000C 120000 R LCALL L?0058 ; SOURCE LINE # 179 000F 0500 R INC dat+01H 0011 E500 R MOV A,dat+01H 0013 AE00 R MOV R6,dat 0015 7002 JNZ ?C0052 0017 0500 R INC dat 0019 ?C0052: 0019 120000 R LCALL L?0058 ; SOURCE LINE # 181 001C 0500 R INC dat+01H 001E E500 R MOV A,dat+01H 0020 AE00 R MOV R6,dat 0022 7002 JNZ ?C0053 0024 0500 R INC dat 0026 ?C0053: 0026 14 DEC A 0027 F582 MOV DPL,A 0029 8E83 MOV DPH,R6 002B E0 MOVX A,@DPTR 002C FF MOV R7,A 002D 120000 R LCALL _print_hex ; SOURCE LINE # 183 0030 850082 R MOV DPL,dat+01H 0033 850083 R MOV DPH,dat 0036 E0 MOVX A,@DPTR 0037 FF MOV R7,A 0038 020000 R LJMP _print_hex ; SOURCE LINE # 184 003B L?0058: 003B 14 DEC A 003C F582 MOV DPL,A 003E 8E83 MOV DPH,R6 0040 E0 MOVX A,@DPTR 0041 FF MOV R7,A 0042 120000 R LCALL _print_hex 0045 22 RET ; FUNCTION _print_hex4 (END)
This is rather .. interesting I suspect it may be the difference of how optimizers behavior between STATIC and pointer analysis. The pointer analysis appears to be the place where things aren't as optimized (although it might not be that easy to transform the code in simplification passes to 'optimal').