the source (shown from the list):
312 3 /* shift out the column data */ 313 3 for (index = 0; index < 8; index++) 314 3 { // column clock to 0, clear column data pin 315 4 SB_P1_FDDA_N = 1; 316 4 if (CPBCsdat & 0x80) SB_P1_FDDA_N = 0; 317 4 CPBCsdat <<= 1; 318 4 delay(); 319 4 SB_P1_FDCK_N = 1; 320 4 delay(); 321 4 SB_P1_FDCK_N = 0; 322 4 } /* end for index */
; ; SOURCE LINE # 313 ;---- Variable 'index' assigned to Register 'R3' ---- 000C E4 CLR A 000D FB MOV R3,A 000E ?C0025: ; SOURCE LINE # 314 ; SOURCE LINE # 315 000E D290 SETB SB_P1_FDDA_N ; SOURCE LINE # 316 0010 EC MOV A,R4 0011 30E702 JNB ACC.7,?C0028 0014 C290 CLR SB_P1_FDDA_N 0016 ?C0028: ; SOURCE LINE # 317 ; SOURCE LINE # 318 ; SOURCE LINE # 319 ; SOURCE LINE # 320 0016 120000 R LCALL ?C0086 ; SOURCE LINE # 321 0019 C291 CLR SB_P1_FDCK_N ; SOURCE LINE # 322 001B 0B INC R3 001C BB08EF CJNE R3,#08H,?C0025
The above is compiled with OT (0) and should thus be without optimization. Is there a way to tell the compiler I am trying to find out how my program works, NOT how the compiler works. In a session with the ICE it should be possible to work without the compiler throwing such curves. Erik
it's the old optimisation-vs-debuggability problem again: http://www.keil.com/forum/docs/thread1673.asp
OT(0) does not mean NO optimization. You might want OT(9,SPEED). ... Please read the manual ;)
"OT(0) does not mean NO optimization." Agreed, OT(0) does include some optimizations, but not any that I would have imagined accounting for that kind of code disappearance or rearrangement. Those kinds of optimizations occur at levels 8 and above. Referring to http://www.keil.com/support/man/docs/c51/c51_optimize.htm , OT(0) is supposed to only include "constant folding", "simple access optimizing", and "jump optimizing". Although it's not my problem, I remain curious for my own education, and have still have not read an adequate explanation accounting for the code production behavior exhibited by Erik's listing.
what happens is that the compiler 'sees' that a given function is preceeded by the same code in some instances e.g.
//a bit =1; hello(); .... //b bit = 0; hello(); ... //c bit = 1; hello(); will compile to ;a call s1 ;b call s2 ;c call s1 s1: sbit bit s2: subroutine ret
"what happens is..." Hmmm, thanks. And just to make sure I understand, that's with OT(0)?
I took your example and extended it a bit as it didn't optimise at all as given: bit a; void hello(void) { volatile char b=1; b++; } main() { a=1; hello(); a=0; hello(); a=1; hello(); a=0; hello(); a=1; hello(); a=0; hello(); a=1; hello(); while(1); } At optimisation level 0 my .cod file was as follows: ----- FUNCTION hello (BEGIN) ----- FILE: 'junk.c' 32: void hello(void) 33: { 34: volatile char b=1; 35: 00000F 750801 MOV b,#01H 36: b++; 000012 0508 INC b 37: } 000014 22 RET ----- FUNCTION hello (END) ------- ----- FUNCTION main (BEGIN) ----- FILE: 'junk.c' 39: main() 40: { 41: 42: a=1; 000015 D200 SETB a 43: hello(); 000017 110F ACALL hello 44: 45: a=0; 000019 C200 CLR a 46: hello(); 00001B 110F ACALL hello 47: 48: a=1; 00001D D200 SETB a 49: hello(); 00001F 110F ACALL hello 50: 51: a=0; 000021 C200 CLR a 52: hello(); 000023 110F ACALL hello 53: 54: a=1; 000025 D200 SETB a 55: hello(); 000027 110F ACALL hello 56: 57: a=0; 000029 C200 CLR a 58: hello(); 00002B 110F ACALL hello 59: 60: a=1; 00002D D200 SETB a 61: hello(); 00002F 110F ACALL hello 000031 ?C0002?JUNK: 62: 63: while(1); 000031 80FE SJMP ?C0002?JUNK 64: } 000033 22 RET ----- FUNCTION main (END) ------- which doesn't show any optimisation at all. I think you must really be compiling with a higher level of optimisation than zero. Stefan