From: "Michael Culley"
Subject: Re: To C or not to C
Date: Sat, 4 Jan 2003 15:47:08 +1100
X-Newsreader: Microsoft Outlook Express 6.00.2720.3000
Mike, Frank, Spehro, Wouter, Walter,
Thanks for the reply.
> This is a religious question and little good can come of asking it.
Some good has already come of it, I know the answer is not black and white.
> Without a well-defined goal .... this it makes no
> sense to ask this question.
Price is of high priority. Coding time is less of a priority as the project
is fairly simple. Size is important as we only have 2 k and might use a
smaller chip if it will save a few cents.
Is the ratio of 3:1 for the C to assembler code typical or are we doing
"Walter Harley" wrote in message
> "Michael Culley" wrote in message
> > First, there is alot of extra assembly code added in that we don't know
> > what it does, if this produces a bug it could be hard to track down.
> The odds of the C compiler or runtimes producing a bug are rather lower
> the odds of you producing a bug. And compiler-generated assembly code is
> generally pretty easy to decipher, especially if you have the C source
> to line it up against.
> > it appears to use alot more of the rom. The assembler version is 757
> > and the C version is 1508 bytes. About 350 bytes is text in both
> If your software is only 400 bytes of assembly then it probably doesn't
> matter what you write it in. As it grows, you may find your productivity
> substantially enhanced by writing in C. Or not. If you want to port to a
> different controller, you will *definitely* find your productivity was
> enhanced by writing in C.
> Note that if you are using an optimizing compiler that knows about your
> particular processor, it may be able to do a better job than you can of
> optimizing performance. And you may have some control over size versus
> The extra memory is "wasted" whether or not there are instructions living
> it. Of course, if your program grows larger, you might hit a boundary
> larger code forces a different chip, which costs money. Conversely, you
> might discover that as the program grows, C lets you manage the additional
> complexity more efficiently.