Now that I've corrected my earlier C-Compiler message, in which
    I confused CCS's "PCB" and "PCM" compilers with the "CC5X"
    compiler, I guess I should respond to some of the specific
    points that CCS's Mark Siegesmund made in his message on the
    subject.

CCS <PICLIST@MITVMA.MIT.EDU> wrote:

> Just to clarify the situation, the CCS compilers are FULL C
> compilers (NOT a "Baby-C") except that they do not have the full
> standard C library (such as file I/O) and the types are limited to
> 1,8,16 bit (no 32 bit and no floating point).  Instead of the
> standard library we supply a PIC specific library.
>
> As for your comparison of MPC/LAB-C and ours you have it backwards.
> Those compilers are a C Subset.  To prove it try multi-dimensional
> arrays, more than two parameters to a function, multi-bit fields
> inside structures or simply arrays of structures in MPC/LAB-C.

    Mark:

    Take your PCM compiler and try pointers to longs, pointers to
    shorts, pointers to consts, arrays of shorts, or -- this is
    really inexcusable -- signed math.

    I'll be kind and say that your compilers and MPC are equally far
    from the ANSI standard.

> You will find MPC/LAB-C falls far short of a "real" compiler and
> except for standard library functions the CCS compilers are
> "real" C compilers.

    Aside from the items I mentioned above, the following examples
    (all perfectly legal) fail to compile under PCM/PCB:

    NOTE:  In all the examples to follow, assume the following
           variable declarations:

        short b;    // b is a single bit.
        long v,w;   // v and w are 16-bit words.
        int x,y,z;  // x, y, and z are 8-bit bytes.

    #1:
    ---

        #define newdef define
        #newdef ten 10

    fails to compile, with an "Invalid Preprocessor Directive"
    error.

    #2:
    ---

        int a[] = {1,2,3,4,5};

    fails to compile, with an "Array dimensions must be specified"
    error.

    "If the array has unknown size, the number of initializers in the
    list deternmines the size of the array" (K&R second edition,
    section A8.7).

    #3:
    ---

        const int a[1] = {1};

    fails to compile with an "Unknown type" error.

    #4:
    ---

    The function prototype

        int func (int);

    fails to compile, with an "Expecting an identifier" error.

    #5:
    ---

        int main (int a)
        {
            return main(a);
        }

    fails to compile, with a "recursion not permitted" error.

    "Recursive calls to any function are permitted", K&R second
    edition, Section A7.3.2.

> The CCS compilers do have full 16 bit arithmetic.

    Well, if you call arithmetic that only knows about non-negative
    numbers "full", I guess this is true.

    That isn't to say, however, that your so-called "full 16-bit
    arithmetic" actually WORKS... PCM generates incorrect code, for
    example, for each of the following trivially-simple statements:

        w = 1 << x;
        x = 1 << w;
        w = x << 4;
        return (v & w) ? 1 : 0;
        if (++w) x = 1;
        if (--w) x = 1;
        if (w || x) x = 1;

    I'm sure there are LOTS more... These are just the ones that I'd
    found after an hour of playing with the compiler.

> In fact, types of 1,8 and 16 bit are supported

    Again, I'm not particularly convinced that your products can be
    called "FULL C compilers" when this support fails to include
    pointers to 1-bit or 16-bit elements, arrays of 1-bit elements,
    type conversions that work, or signed math on ANY of the types.

> As for the optimization, the more inexpensive PCB/PCM do have areas
> where the optimization could be better (PCW does have a higher level
> of optimization) but they always produces less code than MPC/LAB-C.

    This is demonstrably false.

    I won't bore you with a long list of optimization blunders that
    PCM makes, but I should at least point out one of the more
    egregious examples:

        w = x * 256;

    could compile to:

        clrf    w_lo
        movf    x,w
        movwf   w_hi

    but instead, it compiles to 33 instructrions which require
    HUNDREDS of cycles to execute (yes, it calls a general-purpose
    16x16 multiplication subroutine).

    Fix that... It's embarrassing.

> The CCS compilers were designed to get people up an running with a
> new project as fast as possible.  The easy to use built in
> functions, such as RS-232, I/O including formatted printf,  go a
> long way to accomplishing this as do the large number of examples.

    Yeah, the built-in functions are nice, but we're talking about
    the compiler, not its libraries.

    Besides, I hear that those libraries have bugs.

> The product is always being updated with new features suggested by
> customers and we do our best to respond to customer problems ASAP.

    Cool... Here's a problem you can fix. The following program hangs
    the compiler and requires rebooting the computer to recover:

        #define a b
        #define b a
        a

> With a product such as this the more customers there are the better
> the product becomes due to the large number of customers giving the
> product a good "workout."  The low cost has helped us to build this
> large customer base.

    So you're saying that you have over 3000 unpaid beta testers
    each of whose problems are responded to "ASAP", yet you haven't
    discovered or managed to eradicate the bugs I found in just a
    couple of hours?  I don't know what to say to this.

> We are most happy to receive user criticism since this helps us to
> make our better product, however it is disturbing when
> mis-information about the product is so widely distributed.

    Sorry about the PCM/CC5X confusion in my earlier message.  If
    anything I've said in this message is incorrect, please let me
    know.

    By the way, the compiler used for all the examples I gave was
    PCM version 2.204.

    -Andy

    P.S.  Just my opinion... I could be wrong.

Andrew Warren - fastfwd@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499