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
The pattern of code generated indicates that the compiler is keeping the pointer in DTPR, and passing the offset in R7 to L?0039. The complaint is the repeated add to generate the offset for a field. The optimizer can't really peek inside the L?0039 function and inc DPTR; that would be using the DPTR as a global variable secretly passed to this linker-generated library function.
What happens if you write the code this way:
StructA2D* data a2d = &(chan->a2d); OCH = a2d->och; OCM = a2d->ocm; OCL = a2d->ocl; GCH = a2d->gch; GCM = a2d->gcm; GCL = a2d->gcl;
This might cache the pointer to the a2d struct in the DPTR. I haven't tried it, but I'd expect to see a series of calls without the add, just passing in the offsets of the fields inside the a2d struct, rather than going back to the base pointer of chan-> each time. It might even do away with L?0039 entirely.
L?0039 seems like a space optimization. It's eliminating repeated code and turning it into a tiny function. Another way to sidestep the problem is perhaps to favor speed instead of space, at least for this region of code. (You can use #pragma to change the optimizer level.)