Em 13/7/2011 09:26, Bob Ammerman escreveu:
> To whoever was looking for a benchmark run on CCS "C"...
>
> You got me interested so I downloaded the CCS C demo compiler, which is=20
> supposedly the full production optimizations for 45 days. I was not able =
to=20
> get it to work with MPLAB/MPSIM so I wasn't able to get benchmark numbers=
=20
> from it. I did look at the generated code and it was _awful_ compared to=
=20
> Microchip's C30. The first example of this was using a loop of 5 or 6=20
> instructions to shift values bit-by-bit instead of using the barrel shift=
er=20
> built into the PIC24. It really looks like the 16-bit support in this=20
> compiler was just a tweaked version of the 8 bit world. It doesn't even u=
se=20
> the stack, or registers to pass parameters and store locals.
>
> -- Bob Ammerman
> RAm Systems


We discussed CCS compilers some times already.


My first post (2009/01/30) was praising them (I didn't know them
already, only by my friends opinions)

Then as of 2009/08/29 I wrote:

"

I got curious about this compiler and accessed their website.

It looks good, but it has a lot of shortcomings.

It also has some interesting extensions (C++ like) such as function
arguments by reference, function overload and templates, but the
function arguments by reference for instance uses copy to and from,
which is awkward and wasteful of program cycles and space.

The main shortcomings I found are:

- No #elif;
- Passing constant strings to functions first copy them to RAM;
- Crippled heap functions (maximum block length of 127 bytes);
- sprintf accepts only one variable (so not exactly a varargs list)
argument to be printed. Besides, the format specifiers are very
restricted and it can print 16-bit numeric values only. For 32-bit
values there is a sprintf32;
- It is not clear if it has a "printf" function, it has a lprintf which
prints to an LCD;
- Variables declared with the rom storage specifier can only be accessed
through the [] operators;
- rom variables can be used with char data types only;
- A rom pointer is internally limited to 8-bits: the constant array size
is thus limited to 256 elements

"

Then at 2011/03/25 I wrote:

"

I have a client that uses CCS C for a PIC24 project.

Now I need to interface it to my boot-loader (yes, that one) but I can't
find documentation for its function call convention. Besides I could not
find how to change the stack size.

I already searched the Internet, CCS's site and my client's docs, but
there is nothing. Does anybody know this information?

Experimentally I discovered that it passes parameters in temporary
variables (a-la PIC12 and PIC16) and returns bytes and words in W0.

It defines a very small stack (128 bytes), which it uses only for return
addresses (like small PICs). I need to enlarge the stack to at least 256
bytes, because my MPLAB C30 code uses local variables on stack.


Its generated code is also very poor, there is plenty of:

mov w4,w0
mov w0,w0
return

even at maximum optimization level.

It seems that CCS picked their compiler for small PICs and just
"adapted" it for PIC24 devices. I always had CCS as a high-grade
compiler by the words of others. Now I seriously doubt if I would ever
use it.

"


Best regards,

Isaac

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