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

[Mike Harrison]

(posted before but forgot tag....)

WTF is going on with the Hi-Tech compiler that ships with MPLAB....
A few samples below  (all vars are global chars)., target 16F818

Can anyone think of any explanation for such poor code generation other than deliberately making it
slow to make their paid-for compiler look better ?

It can't be doing Microchip any favours shipping such a poor performing compiler with MPLAB as it
makes their chips look slow and inefficient.  


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

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

349:               irtmr1+=bittime2; // bittime2 is a constant
   0DF    300E     MOVLW 0xe
   0E0    00C3     MOVWF 0x43
   0E1    0843     MOVF 0x43, W
   0E2    07F5     ADDWF 0x75, F

Should be 2 instructions


350:               ircnt1++;
   0E3    3001     MOVLW 0x1
   0E4    00C3     MOVWF 0x43
   0E5    0843     MOVF 0x43, W
   0E6    07FB     ADDWF 0x7b, F

Should be 1 INCF instruction

322:               irin=PORTA;
   090    0805     MOVF 0x5, W
   091    00C3     MOVWF 0x43
   092    0843     MOVF 0x43, W
   093    00FC     MOVWF 0x7c

Why is it storing in two places?

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

[Isaac Marino Bavaresco]

Mike Harrison escreveu:

> (posted before but forgot tag....)
>
> WTF is going on with the Hi-Tech compiler that ships with MPLAB....
> A few samples below  (all vars are global chars)., target 16F818
>
> Can anyone think of any explanation for such poor code generation other than deliberately making it
> slow to make their paid-for compiler look better ?
>
> It can't be doing Microchip any favours shipping such a poor performing compiler with MPLAB as it
> makes their chips look slow and inefficient.  
>  

Well, now Hi-Tech belongs to Microchip...

>
> 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
>
> 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
>
> 349:               irtmr1+=bittime2; // bittime2 is a constant
>    0DF    300E     MOVLW 0xe
>    0E0    00C3     MOVWF 0x43
>    0E1    0843     MOVF 0x43, W
>    0E2    07F5     ADDWF 0x75, F
>
> Should be 2 instructions
>
>
> 350:               ircnt1++;
>    0E3    3001     MOVLW 0x1
>    0E4    00C3     MOVWF 0x43
>    0E5    0843     MOVF 0x43, W
>    0E6    07FB     ADDWF 0x7b, F
>
> Should be 1 INCF instruction
>
> 322:               irin=PORTA;
>    090    0805     MOVF 0x5, W
>    091    00C3     MOVWF 0x43
>    092    0843     MOVF 0x43, W
>    093    00FC     MOVWF 0x7c
>
> Why is it storing in two places?
>  

Some time ago I pointed this out, but some people think it is perfectly
normal.


Regards,

Isaac

__________________________________________________
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

[Bob Blick-4]

As Scott and others have hinted at before - you can do almost anything
on a PIC in 12 instructions - HiTech is trying hard - someday they hope
to get CLRF up to 12 instructions but for now it's only 5 :)

HiTech changed when Clyde hired a new president. That's when I stoppped
my maintenance contract with them.

Now that Microchip owns HiTech, perhaps things will change. I imagine
the Microchip forums would be a place to look, there might be chatter
about it.

Cheers,

Bob


Mike Harrison wrote:

> (posted before but forgot tag....)
>
> WTF is going on with the Hi-Tech compiler that ships with MPLAB....
> A few samples below  (all vars are global chars)., target 16F818
>
> Can anyone think of any explanation for such poor code generation other than deliberately making it
> slow to make their paid-for compiler look better ?
>
> It can't be doing Microchip any favours shipping such a poor performing compiler with MPLAB as it
> makes their chips look slow and inefficient.  
>
>
> 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
>
> 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
>
> 349:               irtmr1+=bittime2; // bittime2 is a constant
>    0DF    300E     MOVLW 0xe
>    0E0    00C3     MOVWF 0x43
>    0E1    0843     MOVF 0x43, W
>    0E2    07F5     ADDWF 0x75, F
>
> Should be 2 instructions
>
>
> 350:               ircnt1++;
>    0E3    3001     MOVLW 0x1
>    0E4    00C3     MOVWF 0x43
>    0E5    0843     MOVF 0x43, W
>    0E6    07FB     ADDWF 0x7b, F
>
> Should be 1 INCF instruction
>
> 322:               irin=PORTA;
>    090    0805     MOVF 0x5, W
>    091    00C3     MOVWF 0x43
>    092    0843     MOVF 0x43, W
>    093    00FC     MOVWF 0x7c
>
> Why is it storing in two places?
>

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

[Olin Lathrop]

Mike Harrison wrote:

> 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
>
> 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
>
> 349:               irtmr1+=bittime2; // bittime2 is a constant
>    0DF    300E     MOVLW 0xe
>    0E0    00C3     MOVWF 0x43
>    0E1    0843     MOVF 0x43, W
>    0E2    07F5     ADDWF 0x75, F
>
> Should be 2 instructions
>
>
> 350:               ircnt1++;
>    0E3    3001     MOVLW 0x1
>    0E4    00C3     MOVWF 0x43
>    0E5    0843     MOVF 0x43, W
>    0E6    07FB     ADDWF 0x7b, F
>
> Should be 1 INCF instruction
>
> 322:               irin=PORTA;
>    090    0805     MOVF 0x5, W
>    091    00C3     MOVWF 0x43
>    092    0843     MOVF 0x43, W
>    093    00FC     MOVWF 0x7c
>
> Why is it storing in two places?

It's obviously using location 43h as a sort of working register.  This is
probably due to generating code to handle wide integers run in the single
byte case, and would hopefully dissappear with the optimizer.  If you care
about efficiency, then either use the optimizer or write it in assembly.  It
seems you're getting exactly what you paid for.

The second case looks like it didn't check for the special case of 0 and is
doing some extra instructions to deal with signed/unsigned issues.  Did you
define all the variables unsigned that didn't really need to be signed?
You've got to do your part too, especially when the optimizer is turned off.

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

[William "Chops" Westfield]

>> 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

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

[Isaac Marino Bavaresco]

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

[Terry Harris]

On Fri, 3 Jul 2009 15:32:34 -0700, you wrote:

>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.

I assume you meant Microchip. Microchip do the same with time limited
evaluation and optimisation crippling thereafter for free.

Microchip were doing this before Hi-Tech so perhaps Hi-Tech copied them.
The level of crippling is greater but I doubt it was deliberately so. Their
optimiser seems to be pretty much all or nothing so perhaps there was no
easy way to improve optimisation just a bit.

Previously Hi-Tech crippled the free version with size limits and support
for a very small subset of processors which is better? If you are targeting
a member of that small subset you can still use the old free version.

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

[Dario Greggio (in giro)]

William "Chops" Westfield ha scritto:

> 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 agree with you Bill, I thought the same.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Terry Harris]

On Fri, 03 Jul 2009 20:14:13 -0300, you wrote:

>OK, explain this under this theory:
>
>Look how they do 'Var = 0;' :
>
>bcf    STATUS,C
>*movlw*   0
>btfsc   STATUS,C
>*movlw*   1
>movwf   Var

Evaluate the right hand expression and put the result in something just big
enough (in this case the carry flag). Copy the result to the lvalue.


>'Var = 1;'
>
>clrf   Var
>bsf   STATUS,C
>rlf   Var,f

Same again although I don't know why it chose a different method to copy.


>'Var = 2;'
>
>clrw
>iorlw   2
>movwf   Temp
>movf   Temp,w
>movwf   Var

Same again but the expression needs a file to hold the result.

It seems the compiler is being smart recognising constant expressions of 0
and 1 will fit in a bit and treating them differently. The generated code
looks dumb but I presume provides more scope of optimisation by the bit of
the compiler you didn't buy.

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

[Isaac Marino Bavaresco]

Terry Harris escreveu:

> On Fri, 03 Jul 2009 20:14:13 -0300, you wrote:
>
>  
>> OK, explain this under this theory:
>>
>> Look how they do 'Var = 0;' :
>>
>> bcf    STATUS,C
>> *movlw*   0
>> btfsc   STATUS,C
>> *movlw*   1
>> movwf   Var
>>    
>
> Evaluate the right hand expression and put the result in something just big
> enough (in this case the carry flag). Copy the result to the lvalue.
>  

Makes absolutely no sense. It is testing something itself set hard
coded. And there are two movlw, the expression doesn't have any
conditionals.


>> 'Var = 1;'
>>
>> clrf   Var
>> bsf   STATUS,C
>> rlf   Var,f
>>    
>
> Same again although I don't know why it chose a different method to copy.

Just to grow the code, perhaps?

>> 'Var = 2;'
>>
>> clrw
>> iorlw   2
>> movwf   Temp
>> movf   Temp,w
>> movwf   Var
>>    
>
> Same again but the expression needs a file to hold the result.
>
> It seems the compiler is being smart recognising constant expressions of 0
> and 1 will fit in a bit and treating them differently. The generated code
> looks dumb but I presume provides more scope of optimisation by the bit of
> the compiler you didn't buy.
>  

The temporary location seems reasonable in unoptimized code, but why
load w in a such awkward way?

__________________________________________________
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

[Dario Greggio (in giro)]

Isaac Marino Bavaresco ha scritto:

>>> Look how they do 'Var = 0;' :
>>>
>>> bcf    STATUS,C
>>> *movlw*   0
>>> btfsc   STATUS,C
>>> *movlw*   1
>>> movwf   Var
>>>    
>> Evaluate the right hand expression and put the result in something just big
>> enough (in this case the carry flag). Copy the result to the lvalue.

Hmmm, just a guess from my (limited) experience in writing compilers.

bcf    STATUS,C -> this is a generic "=0" for a bit-type operand

movlw   0
btfsc   STATUS,C
movlw   1
  movwf   Var
-> this is a generic "assign 1 or 0 to a 8bit variable.

Unless optimized further, the "1st step" of the C compiler will generate
this.




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

[sergio masci-2]

On Sat, 4 Jul 2009, Isaac Marino Bavaresco wrote:

> Terry Harris escreveu:
> > On Fri, 03 Jul 2009 20:14:13 -0300, you wrote:
> >
> >  
> >> OK, explain this under this theory:
> >>
> >> Look how they do 'Var = 0;' :
> >>
> >> bcf    STATUS,C
> >> *movlw*   0
> >> btfsc   STATUS,C
> >> *movlw*   1
> >> movwf   Var
> >>    
> >
> > Evaluate the right hand expression and put the result in something just big
> > enough (in this case the carry flag). Copy the result to the lvalue.
> >  
>
> Makes absolutely no sense. It is testing something itself set hard
> coded. And there are two movlw, the expression doesn't have any
> conditionals.

I'll bet Terry is right.

I'll also bet there is a ton of code being executed (inside the compiler)
between the first instruction being generated and the last 4. Just because
you see this 5 instruction sequence together doesn't mean it was all
generated in the same place inside the compiler :-)

Regards
Sergio Masci

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