#include <AT892051.H> #pragma OPTIMIZE (9, SPEED) void main (void) { unsigned char R; R=0; // this statement always produces ASM-code: // CLR A // MOV R7,A // ...!!!!.... why not MOV R7,#0 (2 bytes 1 cycle instead of 2 bytes and 2 cycles) // but, if R=5; is produced code: MOV R7,#05H ;;;;;;; :o) //.... if(P1==0x55) R++; //... //... }
I do not think anyone (at least not in this forum) will argue that Keil makes the best toolset for the '51. However, the constant "move everything through the accumulator" is, indeed a place where the Keil compiler could use some improvement. This improvement, however should not be an optimixztion, but a compiler improvement. One of my basic beefs with the Keil tools is that some things that should be done (and probably could be implemeted better) by the compiler (e.g. switch) are done by the optimizer.
Erik
"... things that should be done [...] by the compiler [...] are done by the optimizer"
I have the same feeling. Another simple example: downcounting loops are not collapsed into DJNZ unless you turn optimizations ON.
Several of the low-level generic functions on my libraries are implemented directly in assembly and prototyped to be called from C, to avoid the compiler lazy translation overhead.
MOV R7,#0
executes in 2 cycles and takes 2 bytes
CLR A MOV R7,A
also executes in 2 cycles and takes 2 bytes. However many times there is a another value 0 required a bit later. I agree that the optimization is a bit random, but in general it is better.
Excuse me, but you are mistaken.
MOV Rn,#data bytes 2 Cycles 1
Look in the bible on MCS51. It's real .