« Return to Thread: : hitech compiler - deliberately generating poor code in free version?

Re: : hitech compiler - deliberately generating poor code in free version?

by Isaac Marino Bavaresco :: Rate this Message:

Reply to Author | View in Thread

William "Chops" Westfield escreveu:

>>> WTF is going on with the Hi-Tech compiler that ships with MPLAB....
>>>      
>
> It used to be that one was taught to have their compiler output  
> "standard format intermediate code" (usually triple operand things  
> that matched no real machines at all:  "operation source1, source2 ==>  
> destination".)   Then, "later", one would write a code generator that  
> would optimize that in ways specific to a destination CPU.  (actually,  
> I guess you get at least three chances to optimize; you can optimized  
> the intermediate code, optimize the generation of real code, and then  
> optimize the resulting machine code.)
>
> The Hi-tech compiler *is* (was?) multi-target, so it probably has some  
> sort of common back-end and does something very like this sort of code  
> generation.
>
>
> I wasn't impressed, back when I was taught this. :-(
>
> I'm not impressed now, when it sort-of looks like Hi-tech has  
> implemented their free compiler by replacing the code generator with  
> something that is at best trivial and perhaps intentionally bad...
>
>  
>> 365:               irrxsum1+=irbyte1;
>>   115    087A     MOVF 0x7a, W
>>   116    00C3     MOVWF 0x43
>>   117    0843     MOVF 0x43, W
>>   118    07F4     ADDWF 0x74, F
>>
>> Should be 2 instructions
>>    
>
> This matches up well with "add irrxsum1, irbyte1 ==> irrxsum1 ?
>
> Also don't forget that C expressions like the source code here are  
> defined to "return" a value, so it's not beyond reasonableness that  
> completely unoptimized code would want to leave the value of each  
> expression calculation in W.
>
>  
>> 366:               ircnt1=0;
>>   119    1003     BCF 0x3, 0
>>   11A    3000     MOVLW 0
>>   11B    1803     BTFSC 0x3, 0
>>   11C    3001     MOVLW 0x1
>>   11D    00FB     MOVWF 0x7b
>>
>> This is especially bizarre - should be 1 CLRF instruction
>>    
>
> Yeah.  Perhaps the compiler has special code to handle common small  
> constants like zero and one, but without optimization the test stays  
> in the code?
>
> I think this was a really bad move on hi-tech's part.  It makes them  
> look bad, it makes compilers in general look bad.  I applaud (sort of)  
> the attempt at a new way of handling "free" versions of commercial  
> compilers, but I really hope that Microsoft decides that this is a  
> failed experiment and does something else in the future.
>
> BillW

OK, explain this under this theory:

Look how they do 'Var = 0;' :

bcf    STATUS,C
*movlw*   0
btfsc   STATUS,C
*movlw*   1
movwf   Var

'Var = 1;'

clrf   Var
bsf   STATUS,C
rlf   Var,f

'Var = 2;'

clrw
iorlw   2
movwf   Temp
movf   Temp,w
movwf   Var

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

 « Return to Thread: : hitech compiler - deliberately generating poor code in free version?