Searching \ for '[PIC]: C language pros and cons' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'C language pros and cons'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: C language pros and cons'
2000\10\06@125223 by Chris Eddy

flavicon
face
Well, Douglas, I would be a little more specific in the attempt to categorize.
When C is used in a PC environment with libraries (IE MFC) and the like, there
is no resemblance to assembly in any form whatsoever.  The trick to C in the
embedded environment is to use it more like a scripting language.  Use ints
instead of floats.  Use a hand made BCD routine instead of sprintf.  Use
pointers in creative ways that help the compiler pack tight code.  As a tool, it
has many forms.  As an embedded tool, it should be used carefully if you intend
to compete with assembly coding.

The up side is programming 5 times faster and writing code which is easily
debugged and maintained by others!  But watch that double edge.

Chris Eddy~

Douglas Wood wrote:

{Quote hidden}

> {Original Message removed}

2000\10\06@140818 by Douglas Wood

flavicon
face
Chris,

I would agree with, but only to a point. Libraries such as MFC could very
easily have an assembly language counterpart. I would argue that the
programmer's choice of libraries, data types, etc. are implementation issues
without regard to the language selected.

I was commenting on Andy's statement that C seem daunting in light of
assembly language; let's face it, an if/then or for/next statement (or any
other construct you care to think of) is "built" pretty much the same in all
languages. Yes, there may be the odd implementation tweak here or there, but
generally speaking all IF statement perform the same function in all
languages, for example.

The programmer's choice of, for example, output routines (hand-made BCD vs.
sprintf) is strictly in the implementation domain; neither choice would
change the programmer's basic understanding of the core language.

As to your statement "As an embedded tool, it should be used carefully if
you intend
to compete with assembly coding", I would caution that you'll never get C to
complete with hand-tooled assembly language code without resorting to using
questionable tricks with, I think, will end up negating any gains made in
creation speed and maintainability. If a routine really needs space or speed
considerations, just go ahead and write it in assembly to begin with.

As for using C in a "PC environment", I always engineer software as if it
were an embedded project! I don't treat a C program running on a PC as
different from a C program running on a PIC, architecturally. Yes,
implementation issues will force design decisions to take one path or
another, but when I'm designing a system, I don't consider implementation
issues until AFTER the behavior model is finished (you, the perfect
technology concept).

And besides, MFC is C++   ;^)

Sincerely,

Douglas Wood
Software Engineer

{Original Message removed}

2000\10\06@180235 by Bob Ammerman

picon face
>
> The up side is programming 5 times faster and writing code which is easily
> debugged and maintained by others!  But watch that double edge.
>
Is the double edge the fact that somebody else can debug and maintain your
code? :-)

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...