Thus spake Andrew Warren (fastfwd@IX.NETCOM.COM):

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

There are two problems with that - firstly you're having a bet each way -
if you are judging the compiler by its usefulness for typical PIC
applications, then issues like recursion and pointers to bits are
irrelevant (you concede yourself that you have no use for recursion,
and I seriously doubt you ever even considered using a pointer to a bit
in an assembler program).

The other problem is, as you said, everyone might have their own ideas about
what they want in a compiler. This leads to the Pascal syndrome, where you
have 746 different and incompatible compilers each claiming to implement
the same language. This is the whole reason for having a standard, and
the standard for C is the ANSI/ISO standard. If you're going to judge
a C compiler against anything I believe this is the only thing you
can judge it against (straightout bugs are, of course, a different
issue).

By this measure the CCS doesn't shape up well, but it isn't claimed to
be ANSI compatible. CCS do compare their product to the competition by saying
"The other compilers we have seen are limited compilers that only resemble
real C". I don't see anywhere that they claim their compiler DOES resemble
"real C", whatever that is. The claim in this mailing list that the CCS
compilers are "full C" is equally fuzzy.

Now ANSI C lacks a few things needed for embedded work; specifically:

* Support for multiple address spaces (ANSI C supports only one code and one
  data address space)
* Simple access to hardwired addresses
* Interrupt support
* Bit variables

There are other things, but they can mostly be provided without altering the
language. The points above are difficult to support in an ergonomic fashion
without extending the language - the challenge is to do so in a way that
alters the language as little as possible.

But given minor extensions, ANSI C can do an excellent job on low-end
microcontrollers, with a good optimizing compiler. And using a standard
language allows you to use such features as long or float arithmetic if
you need them (but suffer no cost if you don't).

The huge benefit of using an ANSI compiler on a PIC is not so much portability
of code (which is important, but less so than on larger processors) but
portability of people, i.e. programmers.

Anyway, getting back to CCS - apart from the issue of bugs, which presumably
can be fixed, providing it's not claimed to be a standard C compiler, and
it's limitations are documented and understood by the user, it's probably
very adequate for some applications, and it's certainly cheap. I suspect
it represents rather better value for money than Bytecraft's or Microchip's
compilers, which suffer from their own problems, and are certainly not
ANSI compliant either. Cost aside, whether it's "better" than those
products will depend on the application for which it is used.

For the record, I think using "short" for a bit variable, and "long" for
a 16 bit is a Bad Idea, as is Bytecraft's thing.0 notation for bit access.
These are unnecessary and confusing.

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
clyde@htsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/