Clyde Smith-Stubbs <PICLIST@MITVMA.MIT.EDU> wrote:

> Sorry Andy, I just have to butt in here about a couple of things -
> I've got no real experience with CCS's products, but these things
> need rebuttal .... You cannot define new preprocessor directives
> under ANSI C.

    Clyde:

    Thanks for the info... I didn't know that.

> >         int main (int a)
> >         {
> >             return main(a);
> >         }
> >
> >     fails to compile, with a "recursion not permitted" error.
>
> Non-ANSI, yes, but it is architecturally impossible to implement
> recursion in any reasonable manner on a PIC, owing to its lack of
> anything closely resembling a stack.

    I didn't say it would be easy, or even that I like using
    recursive functions (I don't).  This was simply one in a series of
    rebuttals to the claim that the CCS compilers are "full C".

> BTW Andy, when discussing ANSI C it is better to reference the ANSI
> standard rather then K&R, which has a few errors.

    True... But K&R's all I have.

> I'd also remind you that ANSI permits a free-standing
> implementation some latitude in certain features compared to a
> hosted implementation of C.

    I'm not sure how the issue became "ANSI C" compatibility.

    Mark didn't claim that his compiler was ANSI-compliant, and I
    wouldn't hold any embedded-C compiler to that standard, anyway...
    Although I mentioned ANSI once in my last nessage, what I was
    really trying to discuss was whether the compiler was compliant
    with the (admittedly less formal) definition of a "full" C
    compiler.

    We each may have our own ideas of what constitutes "full C" for a
    small embedded processor.  Rather than nitpicking about features
    like floats, pointers to functions, etc., I tried to choose
    features and operations that are likely to be used in a small PIC
    application.

    I admit that the cross-referenced #defines that crash the
    compiler, and the preprocessor-directive redefinition that you
    mentioned above, were somehwat contrived.

    I think the rest of my examples, though, were pretty realistic.

> Your comment about lack of pointers to single bits is off the mark -
> since there's no bit pointer type supported by the hardware and to
> implement it in software would be horrendously inefficient, it's
> best left out (and since single-bit variables are not an ANSI
> feature, that's not an issue).

    Again, I didn't mean for the issue to be ANSI compliance. Arrays
    of bits (and/or pointers to bits) are VERY commonly used in PIC
    applications; a compiler that supports single-bit variables should
    also support arrays of, or pointers to, those variables.

    Besides, 16-bit variables aren't directly supported by the
    hardware, either, but the CCS compilers manage (more or less) to
    support THEM.

> I have no comment to make on the other problems you found except to
> say that if accurate, they need attention.

    They're accurate when compiled with the version of PCM (2.2.04)
    that I used for my tests.

    I'm aware that there are newer versions of the CCS compiler... I
    suspect that some of the issues I raised have been addressed in
    those later versions.

    Nevertheless, the fact that I was able to find those bugs so
    quickly implies -- as everyone who's done any formal software
    testing knows -- that there are many more bugs waiting to be
    found.

    I hope no one (including Mark Siegesmund at CCS) takes my
    comments the wrong way... I have no doubt that PCM (even with
    the shortcomings I mentioned) is suitable for many PIC
    applications, and I certainly have no personal ax to grind with
    CCS.

    -Andy

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