John J. McDonough wrote:

> Actually, I'm not sure but I think the most pathological example I've
> seen was the HiTech compiler.

There may be inefficiencies. But so far I haven't run into a problem with
compiler efficiency. 

>> I of course agree that one should program in C differently on a PIC than
>> one would on a PC. But I guess that's obvious... :)
> 
> Yeah, and if you know that, you are one of those guys who has enough
> understanding of the space to use a compiler effectively.  If you are a
> newbie, or worse yet an experienced C programmer, it's not so obvious. 
> And that's the point.  Compilers aren't bad, its just that on the PIC
> they're not for rookies.

I carefully disagree... :)  When I started out with the PIC, I was an
experienced C programmer. Ok, I knew other micros, but didn't know the PIC
architecture. And it /is/ a bit, hum, different. After reading up on it, I
knew enough to be somewhat familiar with it, but not enough to write
decent-sized programs efficiently in assembler. But that was enough to get
me going quickly with a C compiler. I learned pretty much all of the
assembler I know from looking at generated code (or at code written by
others), not from writing it myself.

The hardware modules like timers, SPI etc. have all their idiosyncrasies,
but most things are similar between different families of micros, and once
you read through the manual, you kind of get most of it. (Of course you
need to read it again and again for the missing details... :) What's really
hindering early and quick productivity are all these little things in a new
assembler language: where does the data come from? where is the result?
what status bits get set? what constructs/instruction sequences are
efficient to do X? and so on. Writing in C, you can get by with a basic
understanding of the architecture, a decent understanding of the hardware
modules you are using, and a certain understanding of C and its general
limitations on smaller micros -- without having to learn the assembler to a
point where you can write quickly and efficiently in it. For an assembler
programmer, even the switch from the 14 bit family to the 16 bit family is
a step: new instructions, new possibilities, new things to learn. When
programming in C, I don't really care whether I'm writing for a 14 bit part
or for a 16 bit part. (Well, almost; the stack use is of course an issue on
the 14 bit parts.)

I can write quickly and efficiently PIC programs by now, and I think I know
the architecture fairly well by now, but I still can't write quickly and
efficiently PIC assembler. I can read it pretty much fluently, and I can
figure out how to do simple things that may need to be done in assembler
(even though I never had to). And that's all I need; I have no desire to
actually learn how to write PIC assembler.

> I agree that if you're writing big stuff, a compiler can be a wonderful
> thing to help with all the messy paging issues and the like.  But for
> most stuff, a little care in organizing your modules and that isn't
> really a big issue anyway. 

Exactly -- just because you're writing in C doesn't mean you won't have to
apply common sense and acquire a certain level of understanding the
architecture. But for me, that's not an argument against using a compiler;
I generally use the compiler to help me in acquiring that understanding.
When writing for a different architecture, I usually take quite a few peeks
at the generated code in the beginning, to get an understanding of how it
performs the normal stuff, like branching, looping, argument passing, and
so on, and how it changes the code when optimizing.

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