Searching \ for '[PIC] : hitech compiler - deliberately generating' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: ': hitech compiler - deliberately generating'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] : hitech compiler - deliberately generating '
2009\07\03@132700 by Mike Harrison

flavicon
face
(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?

2009\07\03@140218 by Isaac Marino Bavaresco

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


{Quote hidden}

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/

2009\07\03@140517 by Bob Blick

face
flavicon
face
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:
{Quote hidden}

2009\07\03@154314 by olin piclist

face picon face
Mike Harrison wrote:
{Quote hidden}

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.

2009\07\03@183236 by William \Chops\ Westfield

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

2009\07\03@191417 by Isaac Marino Bavaresco

flavicon
face
William "Chops" Westfield escreveu:
{Quote hidden}

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/

2009\07\03@191957 by Terry Harris

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

2009\07\03@195150 by Dario Greggio

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

2009\07\03@200457 by Terry Harris

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

2009\07\04@090957 by Isaac Marino Bavaresco

flavicon
face
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?

{Quote hidden}

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/

2009\07\04@092759 by Dario Greggio

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




2009\07\04@093348 by sergio masci

flavicon
face


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

{Quote hidden}

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

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...