On Thu, 2008-03-06 at 09:32 -0800, Bob Blick wrote:
> OK, Olin, I'll take you on. Let's see you switch to a different
> architecture(non-PIC) and make that claim. No, you can't have a month to
> make libraries of needed functions, but you must create those reusable
> needed functions while developing your program.
> 
> See, it takes more time to do a project in assembler now!
> 
> Also judging from years of experience reading your posts, I think you
> are an exceptional person, and being an exception, just using you as an
> example would be a poor sample. To do this properly we need to get a
> group of programmers, plop them in a room with some weird processor, and
> half of them use assembler and half use C. Then switch and try again.

Bob, I think you've hit the exact reason I prefer using an HLL:
portability.

If you are just using PICs I can see the argument for sticking with ASM.
Assuming you've accumulated all the libary routines you need it is a
wise choice since you are only open to flaws in the assembler, which is
relatively problem free.

The issue is the MOMENT you want to move to different hardware you're
toast. PICs REALLY lock you in with their weird architecture,
translating PIC ASM to say an 8051 MCU would be more hell then I'd be
willing to endure.

For me, all my routines are in C, purposely written in such a way that
they are relatively immune to hardware changes, and even compiler
oddities (i.e. how many bits is an int, is a char unsigned or signed by
default, what's the compilers default radix, etc.).

This doesn't always result in the simplest of code (i.e. my printstring
routine calls a putchar routine) but it does aid in portability. Taking
the example of a printstring function, since it calls putchar, the only
change I have to make when porting my code is putchar, a very simple
function. The change is often just a single line of code (i.e. calling
the UARTwrite library function of the MCU I'm working on).

I've used my library of routines for PICs (12F/16F, 24Fs and 30Fs),
AVRs, Stellaris MCUs, Windows apps, linux apps, and have ever
"transcoded" some of them to HDL (Verilog!).

I like to keep my options open, who knows what my job or hobby will
require of me with regards to MCU/CPU family, I want at least the option
to leverage my prior work.

All that said, there do come times when the "bloat" of this ideal is of
a concern, in those cases I've had to optimize my code more for the
hardware/compiler then I'd normally like. I've even had to plunk in some
ASM from time to time for REALLY timing critical code. Still, the vast
majority of my coding is C/C++ these days.

> Finally, I'm glad you chose C18 as your example of a bad C compiler. I
> agree with you there :) The only good thing about it is that it does
> work and is supported.

Even more importantly, Olin choose MChip's TCP/IP stack, a truly
difficult piece of code to get one's head around! :)

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