> If they did not produce horrible code for the free version, would people
> really pay $$$$ for a 10% to 20% improvement in the paid version?

That's a conspiracy theory only :-) Let's look it in the other way around:
If the free version produces horrible code - would you believe that the
professional version is any better?

BTW: Just playing with AVR + GCC - same thing, when optimization is off then
the code is horrible + avr-gcc is even worse in terms of how it puts the SFR
symbols. They use #define-s therefore no symbolic info. Now Kernighen has
right ;-)

Tamas



On Mon, Sep 15, 2008 at 6:50 PM, William Couture <bcouture@gmail.com> wrote:

> On Fri, Sep 12, 2008 at 5:51 PM, Philip Pemberton <piclist@philpem.me.uk>
> wrote:
>
> > Wouter van Ooijen wrote:
> >> But the discussion Mike pointed to seems to be about the same issue, a
> >> pity they did not update their main download. To get the patched version
> >> I must again register, sigh...
> >
> > I found this quite amusing:
> >
> >     92                                 line    18
> >     93                           ;main.c: 18: PORTA = 0;
> >     94  0001  1003                     clrc
> >     95
> >     96  0002  3000                     movlw   0
> >     97  0003  1803                     btfsc   status,0
> >     98  0004  3001                     movlw   1
> >     99  0005  0085                     movwf   (5)     ;volatile
> >
> > Even with optimisation off, there is no way *any* compiler should
> generate
> > code this bad. It's almost as if it were deliberately designed to
> generate
> > this sort of garbage...
> >
> > The write-to-TRIS code is even more amusing:
> >
> >    108                                 line    22
> >    109                           ;main.c: 22: TRISA = 0b00000100;
> >    110  000B  3004                     movlw   (04h)
> >    111  000C  00F0                     movwf   (??_main+0+0)
> >    112  000D  1683                     bsf     status, 5       ;RP0=1,
> select bank1
> >    113
> >    114  000E  0870                     movf    (??_main+0+0),w
> >    115  000F  0085                     movwf   (133)^080h      ;volatile
> >
> > That's right folks. It saves the 0x04 in a temporary variable, sets RP0,
> then
> > proceeds to read the value from said temporary variable and move it into
> > TRISA. Instead of just setting RP0, MOVLW'ing, then MOVWF'ing.
> >
> > It even does this if it doesn't have to change RP0/RP1:
> >    167                                 line    34
> >    168                           ;main.c: 34: CCP1CON = 0b00001110;
> >    169  002E  300E                     movlw   (0Eh)
> >    170  002F  00F0                     movwf   (??_main+0+0)
> >    171
> >    172  0030  0870                     movf    (??_main+0+0),w
> >    173  0031  0095                     movwf   (21)    ;volatile
> >
> > I've seen some pretty bad compilers, but this one doesn't just take *the*
> > biscuit, it takes the entire contents of the McVitie's warehouse, then
> holds
> > up its dinner plate and says "Please Sir, I want some more!"
> >
> > (I mean, I know it's a demo - and that optimisation is disabled - but
> using a
> > temporary variable to write to a hardware register? That's by far and
> above
> > the biggest WTF I've ever seen. Even worse than some fairly recent code I
> > found that spawned 'awk' to trim a few characters off the end of a
> string.)
> >
> > Here's the code I was testing with:
> >
> > /// --- snip code
> > // device: PIC16F616
> > #include <htc.h>
> > __CONFIG(INTIO & OSC_8MHZ & UNPROTECT & MCLREN & PWRTDIS & WDTDIS &
> BORDIS);
> >
> > void main(void)
> > {
> >        // Clear port registers
> >        PORTA   = 0;
> >        PORTC   = 0;
> >
> >        // Set up TRIS registers
> >        TRISA   = 0b00000100;
> >        TRISC   = 0b00000000;
> >
> >        // Set up A/D converter
> >        ANSEL   = 0b00000100;           // AN2 analog, rest digital. TODO:
> Vref external!
> >        ADCON1  = 0b00110000;           // Clock A/D from Frc (~500kHz)
> >        ADCON0  = 0b11001001;           // Right justified, ref=Vcc (TODO:
> Vref external!)
> >
> >        // Set up CCP for PWM
> >        T2CON   = 0b00000110;           // TMR2 on, 1:16 prescale, no
> postscale
> >        PR2             = 0xFF;                         // PR2 set for max
> resolution. Fpwm=488.28Hz with 8MHz and
> > 1:16 prescaler
> >        CCPR1L  = 63;                           // Set PWM initial duty
> cycle
> >        CCP1CON = 0b00001110;           // Set PWM mode -- P1A modulated
> (rest I/O), active low
> >
> >        for (;;);
> > }
> > /// --- snip code
> >
> > Now if you'll excuse me, I'm going to get a very large cup of tea before
> I die
> > laughing.
>
> It would not surprise me if this was deliberate.
>
> They are now advertising that they have a free version of their compiler
> that
> works with all PICs and no limitations.
>
> However, the registered version is supposed to produce code that is
> half the size of that produced by the free version.
>
> If they did not produce horrible code for the free version, would people
> really pay $$$$ for a 10% to 20% improvement in the paid version?
>
> And I really should compare the results of the previous, "limited" free
> version against the new free version.  I'll bet that the "limited" free
> version is much better than the "improved" version.
>
> Bill
>
> --
> Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



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