From: Scott D. <sc...@da...> - 2004-03-23 05:59:42
|
I was looking at the pic14 port and saw some strange code generated for a complement operation. Essentially, bytes were getting cast to ints. I then tried the same code on the mcs51 port and saw the same type of code. In the pic regression tests is a file called and2.c that contains this function: unsigned char failures=0; unsigned char uchar0 = 0; void neg_compound1(void) { uchar0 = ~(uchar0 + 1); if(uchar0 != 0xeb) failures++; } Using yesterday's CVS I placed this function into 't.c' and ran: $ sdcc -mmcs51 -S t.c And examined t.asm: ;------------------------------------------------------------ ;Allocation info for local variables in function 'neg_compound1' ;------------------------------------------------------------ ;------------------------------------------------------------ ;t.c:5: void neg_compound1(void) ; ----------------------------------------- ; function neg_compound1 ; ----------------------------------------- _neg_compound1: ar2 = 0x02 ar3 = 0x03 ar4 = 0x04 ar5 = 0x05 ar6 = 0x06 ar7 = 0x07 ar0 = 0x00 ar1 = 0x01 ;t.c:7: uchar0 = ~(uchar0 + 1); ; genCast mov r2,_uchar0 mov r3,#0x00 ; genPlus ; genPlusIncr inc r2 cjne r2,#0x00,00106$ inc r3 00106$: ; genCpl mov a,r2 cpl a mov r2,a mov a,r3 cpl a mov r3,a ; genCast mov _uchar0,r2 ;t.c:8: if(uchar0 != 0xeb) ; genCmpEq mov a,_uchar0 cjne a,#0xEB,00107$ ; Peephole 112.b changed ljmp to sjmp ; Peephole 251.b replaced sjmp to ret with ret ret 00107$: ;t.c:9: failures++; ; genPlus ; genPlusIncr inc _failures 00103$: ret As you can see, the unsigned char is type casted to an int and then assigned back to a char. All the crazy business with the high byte is never used. Does anyone know why this is the case? As a second observation, in this particular example: uchar0 = ~(uchar0 + 1); is equivalent to uchar0 = 0xfe - uchar0; or better: uchar0 = ~uchar0 - 1; In PIC assembly, the original sequence can be implemented with INCF uchar0,F COMF uchar0,F while the latter sequence: COMF uchar0,F DECF uchar0,F Scott |
From: Bernhard H. <ber...@be...> - 2004-03-23 08:50:26
|
> As you can see, the unsigned char is type casted to an int and then > assigned back to a char. All the crazy business with the high byte is > never used. Does anyone know why this is the case? I should know, I'll have a look. Bernhard |