On 29/06/2011 13:27, mcd@is-sixsigma.com wrote:
> The exception seems to be SDCC.  It almost never produces good code, but
> as best I can tell, it never seems to come up with pathological code,
> either.
>

Ah yes.. I looked at it.
Some promise, but basically a work in progress. I think it's the worst=20
for PIC.
If you really want to do C, Hitech C (now bought by Microchip) might be=20
best.
I  think I may even used a Z80 version back in late 1980s.
On 16F877 once it produce code for a case statement that was wrong. We=20
never figured why. Looking at the Assembler we could see the logic was=20
wrong.
Replacing the offending section with a bunch of "ifs" fixed it. That's=20
the only really memorable "bug".

I've ported even some parts of Linux application C code for x86 to JAL=20
and also VB6 on Windows fairly painlessly, so even if you have a lot of=20
existing C code for 8051 or something, it's no big deal to re-write for=20
JAL, and maybe find a bug or two that slipped by before.

I really really didn't like the 8051. Back in early 1980s I was also=20
using NEC 78C11 (six galvanically isolated slave controllers for I/O on=20
Z80 master CPU). I used its Macro Assembler to build a Forth like=20
environment and wrote 16bit math library in assembler for it. (only=20
match instructions 8 bit add, shifts, and  complement) It was easier to=20
work with even though no ICD than the 8051 with ICD and assembler or C.

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