The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: "D Poinsett"
Subject: Re: To C or not to C
Date: Sat, 4 Jan 2003 07:28:32 -0500
Organization: Posted via Supernews, http://www.supernews.com
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
The serious embedded software designer will often need both C and assembler
for projects that require efficient use of the programmer's time and speedy
operation. For small projects (<32K) that require no floating point I highly
recommend the Dunfield C compilers. Available for numerous processors, these
compilers are modestly priced, reliable, all code in the library is
provided, the output is very tight, inline assembler is supported, the
compiler only invokes sections of the library that are actually used, and
the products are well supported. I've been using Dunfield stuff for about 10
years and love it. Having the code to the library is a joy because you can
tweak it to your own unique needs.
The Dunfield compilers may be configured to provide assembly listings of the
final code (even after optimization) so you have the option to examine the
results at this level of detail. Although I frequently use inline assembler,
I have been surprised at the number of times that I could not do much better
than the compiler in terms of efficiency or code size particularly for more
complex functions. It also lets you see how the compiler produces the
results so you can code in C in ways that take best advantage.
Many newer processors are designed knowing that the firmware will likely be
written in stack intensive languages like C and therefore include on-chip
hardware and assembly instructions that maximize efficiency for these
operations. The Moto HC12 family is a good example.
I have built a nice C function library over the years and this has made it
very easy to start using new processors. You will not regret learning and
using C if you are serious about embedded system design.
One final note: you would be surprised how much you can do without floating
point math. Eliminating this from your C library will save lots of room in
projects where code size is critical. Smaller and faster scalable
long-integer functions (included in the Dunfield suite) will often take care
of most higher precision math when needed.
"Michael Culley" wrote in message
> Thanks to everyone's help here my small project has progressed well. I now
> had a completed (although very messy) prototype. For those who didn't read
> my previous thread it is using an 8051 and a max232 to connect to a serial
> port. I'm doing this project with a friend and he prefers to use C while I
> prefer to use assembler. We have both written the software and both
> work the same with only minor differences. I can see 2 problems with using
> C. 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.
> it appears to use alot more of the rom. The assembler version is 757 bytes
> and the C version is 1508 bytes. About 350 bytes is text in both, so the C
> code is almost 3 times larger than the assembler version. The C version
> had quite a few hours spent on it getting it down to 1500 bytes where the
> assembler version hasn't been optimised. 1500 bytes seams like a huge
> when we only have 2k.
> What does everyone think, which is better C or assembler? We are using
> Michael Culley
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup