Eddie Starling wrote:

> I'm looking for an inexpensive C compiler for PIC processors. Has
> anybody had any experience with the CCS compiler. I'm looking at the
> 14 bit compiler (PCM). Are there any others worth considering.

... and Dag Bakken <PICLIST@MITVMA.MIT.EDU> replied:

> You should have a look at the CC5X C-Compiler.  This compiler
> supports the 12-bit and 14-bit PIC core.

    But not the 16-bit core.

> This is (as far as I know) the oldest PIC C-compiler available (i.e
> very well debugged).

    While the compiler itself has very few real bugs, the libraries
    included with it (which are the most compelling reason for
    anyone to buy the compiler) often DO have serious bugs... New
    revisions of those libraries seem not to be tested very well by
    CCS before they're released.

> CC5X will also generate the most compact code, and reuses RAM
> whenever possible.  This is the main advantage of this compiler.
> When most compilers have filled up your ROM, CC5X may be able to
> generate the same program in 2/3 of the space.

    It's important to note that:

    1) CCS doesn't use any high-powered optimization algorithms or
       anything... The compactness of their generated code is due
       almost entirely to the fact that the compiler only supports
       a "Baby-C" subset, limited to the operations that are DIRECTLY
       supported by the PIC instruction set.  16-bit math, for
       example, is not directly supported; in fact, the compiler
       doesn't even support SIGNED math.

    2) The CCS compiler doesn't really generate code that's all THAT
       compact, anyway.

    Here's a simple example of optimization failure:

        byte1 = x;
        byte2 = x;
        byte3 = x;

    In this case, the compiler produces:

        movf    x,w
        movwf   byte1
        movf    x,w
        movwf   byte2
        movf    x,w
        movwf   byte3

    The trivial optimization that the compiler misses is, of course:

        movf    x,w
        movwf   byte1
        movwf   byte2
        movwf   byte3

    "A-ha!" you say, "But what if 'x' is an I/O port?  In THAT case,
    the optimized code might be inaccurate."

    Well, ok... But shouldn't a compiler written specifically for
    the PIC know the difference between an I/O port and a
    general-purpose file register?  I mean, really...

    Besides, when the compiler's given:

        byte1++;

    it compiles it to:

        movf    byte1,w
        incf    byte1

    What's up with THAT?

> The most frequent question from customers, is how to implement
> inline assembly...  This is something that is not possible, and you
> don't need it.

    You DO need it, and it IS possible... To write inline assembly,
    just bracket your assembly code with #ASM and #ENDASM directives.

    I know that Eddie didn't want to spend a lot of money, but if
    anyone else on the list is looking for a "real" C compiler, I
    recommend MPC and MPLAB-C.

    -Andy

=== Andrew Warren - fastfwd@ix.netcom.com                 ===
=== Fast Forward Engineering - Vista, California          ===
===                                                       ===
=== Did the information in this post help you?  Consider  ===
=== contributing to the PICLIST Fund.  Details are at:    ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===