gnupic: Re: [gnupic] What About GCC and PIC's
Subject:
Re: [gnupic] What About GCC and PIC's
From:
Martin McCormick ####@####.####
Date:
8 May 2005 03:34:11 +0100
Message-Id: <200505080234.j482Y7T3018376@dc.cis.okstate.edu>
Peter writes:
>No, it's because it makes cpu migration and code maintenance relatively
>painless.
That is true, and a higher-level language like C also makes
things like arithmetical operations and string manipulation trivial
and standardized. The only PIC programming I have written has been
in assembler and assembler is sufficient when one is working on a
fairly simple project in which bit-wise logical operations are what
the project is all about such as a noise maker or the brains behind an
infrared remote receiver or transmitter, (and a whole lot more of that
kind of stuff).
Then, you get in to devices that need to perform calendar
functions or encryption/decryption using algorithms a little more
complicated than the exclusive or of value A with Value b, etc. There
are software engineers who have written whole navigation and guidance
systems in assembler, probably even in machine language, but I bet the
effort was huge converting calculous-based algorithms to assembler or
machine code that actually worked correctly.
I have read arguments by a few individuals on the main PIC
list who wouldn't touch a C compiler and do all their coding in
assembler. I don't understand that argument, but I also will probably
use assembler in many cases and use C to take advantage of all the
standard libraries for arithmetic operation and data processing that
are a pain to deal with in straight assembler. Even if one develops
lots of code blocks for doing whatever strikes one's fancy in
assembler, it seems like there is always something in one's new
program that keeps the code from fitting without a little hammering
so to speak.
The best of both worlds will come if we can write modules in C
and other modules in assembler, if necessary.
The late Admiral Grace Hopper was the creator of the first
assembler when she and her team got tired of having to do so much work
each time just to write a simple program. The bottom line to me is to
get as much done with as little repeat effort as possible.
Higher level languages are force multipliers. As long as they
produce efficient code that has some hope of fitting on the device in
question, we are talking about an advancement in the state of the
art. It's not better than assembler, but kind of picks up where the
assembler leaves off.
Martin McCormick WB5AGZ Stillwater, OK
OSU Information Technology Division Network Operations Group
