PIC mplab c18 C compiler

On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
> darkknight <darkknight.21@gmail.com> wrote:
>> 
>> Do you have any idea which of IAR, HI-tech or CCS would be the most
>> reliable - trouble-free?
>
> IAR, by orders of magnitude. It's the only C compiler on PIC that is
> even *remotely* like using C on a more conventional micro. Expensive,
> but you get what you pay for. The code density isn't bad too these days.

In what ways is IAR "orders of magnitude" better than Hi-Tech?

-- 
John W. Temples, III

stack based with re-entrancy
dyn mem alloc 

John Temples <usenet@xargs-spam.com> wrote:
> On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
>> darkknight <darkknight.21@gmail.com> wrote:
>>> 
>>> Do you have any idea which of IAR, HI-tech or CCS would be the most
>>> reliable - trouble-free?
>>
>> IAR, by orders of magnitude. It's the only C compiler on PIC that is
>> even *remotely* like using C on a more conventional micro. Expensive,
>> but you get what you pay for. The code density isn't bad too these days.
> 
> In what ways is IAR "orders of magnitude" better than Hi-Tech?


ANSIness. Reentrancy (if you want it). Ability to declare "generic"
pointers that can address data or code space. (OK, this leads to hideously
inefficient code, but it means *you can construct platform-independent
code and expect it to run on a PIC*. Yes, it's inefficient relative
to something designed specifically for a PIC's architecture, but in
a world where systems are increasingly constructed from the output of
code-generation tools, this is often very important.

Hi-Tech is OK if you want something for developing "PIC applications"
with; if you want to do "real programming" that just happens to target
the PIC, IAR is the only choice. CCS is... something that looks a bit
like C.

pete
-- 
pete@fenelon.com "there's no room for enigmas in built-up areas"

On 2005-12-18, Pete Fenelon <pete@fenelon.com> wrote:
> John Temples <usenet@xargs-spam.com> wrote:
>> On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
>> In what ways is IAR "orders of magnitude" better than Hi-Tech?
>
> ANSIness. Reentrancy (if you want it). Ability to declare "generic"
> pointers that can address data or code space.

Hi-Tech has all of that except reentrancy (which I don't want).  It
also has a reasonable code generator, which IAR did not in my last
evaluation.  An application that generated 24K of code with Hi-Tech
generated 36K of code with IAR, and didn't even fit in the target's
32K of flash.

> *you can construct platform-independent
> code and expect it to run on a PIC*.

Do you feel that's not possible with Hi-Tech?  I have no problems
doing it.

-- 
John W. Temples, III

On Sun, 18 Dec 2005, Pete Fenelon wrote:

> John Temples <usenet@xargs-spam.com> wrote:
> > On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
> >> darkknight <darkknight.21@gmail.com> wrote:
> >>> 
> >>> Do you have any idea which of IAR, HI-tech or CCS would be the most
> >>> reliable - trouble-free?
> >>
> >> IAR, by orders of magnitude. It's the only C compiler on PIC that is
> >> even *remotely* like using C on a more conventional micro. Expensive,
> >> but you get what you pay for. The code density isn't bad too these days.
> > 
> > In what ways is IAR "orders of magnitude" better than Hi-Tech?
> 
> 
> ANSIness. Reentrancy (if you want it). Ability to declare "generic"
> pointers that can address data or code space. (OK, this leads to hideously
> inefficient code, but it means *you can construct platform-independent
> code and expect it to run on a PIC*. 

Yes all ten lines of it - if you're lucky.

>Yes, it's inefficient relative
> to something designed specifically for a PIC's architecture, 

That's such an understatement, it's like saying "a rocket is a little 
beefed up compared to a kite".

>but in
> a world where systems are increasingly constructed from the output of
> code-generation tools, this is often very important.

It's a bit pointless if the generated code wont fit in a PIC or executes 
too slowly.

Good code generation tools for embedded targets do exist. Relying on 
tools "hacked" together by programmers (and I use the term VERY losely 
here) that know nothing about embedded or realtime systems is a big 
mistake. If you are using a tool that cannot take advatage of the 
properties of a particular target, either get a new tool or hire someome 
that can do the job properly.

> 
> Hi-Tech is OK if you want something for developing "PIC applications"
> with; if you want to do "real programming"

So what anything else is not "real programming" ?

> that just happens to target
> the PIC, IAR is the only choice. CCS is... something that looks a bit
> like C.



Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.

On Fri, 16 Dec 2005 21:03:55 +1300, darkknight
<darkknight.21@gmail.com> wrote:

>
>
>Hi
>
>A colleague of mine is using MPLAB C compiler and is struggling with the
>saving of registers in ISRs.  Apparently the compiler manual says you
>have to manually scan the assembler code generated by the compiler to
>work out what registers to save/restore in interrupt routines.  His
>software is crashing and he appears to be struggling to solve the
>problem.
>
>Does anyone have any experience with this C compiler?
>
>Is there an easy way to determine what registers to save?
>
>Are there any more reliable C compilers for the PIC micro than MPLAB?
>
>Is the PIC micro tricky to use with lots of gotchas?
>
>TIA

You could also look at Knudsen Data's compiler http://www.bknd.com/
for the PIC. I've just come across this one, does anyone have any
experience of it?

Vic