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: Jonathan Kirwan
Subject: Re: To C or not to C
References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
X-Newsreader: Forte Agent 1.92/32.572
NNTP-Posting-Date: Sun, 05 Jan 2003 21:03:18 GMT
Organization: AT&T Broadband
Date: Sun, 05 Jan 2003 21:03:18 GMT
On Sun, 5 Jan 2003 11:18:38 -0500, "D Poinsett"
>I misunderstood. I thought you were saying that there are operational
>functions in the resulting code that could be done in assembler but not C
>due to the semantic limitations of C.
>I don't view this as "C or assembly language" issue. I think that for
>projects of more than a few K, the embedded designer needs both a high level
>language and assembly. I cringe at the thought of managing a large project
>without a high level language. I prefer C because it lets me get pretty
>close to the hardware and is relatively efficient for embedded designs. But
>I would be in dire straights if I could not directly manipulate the
>processor with inline assembly.
In general, I'm congruent with the above. I also prefer an
environment which supports separate compilation, including
separate assembly modules. Inline assembly often works, but it
won't provide those linktime constants I mentioned, for example.
>Your first example is about managing symbols and the project overall.
>Judicious use of #defines, pre-compiled libraries (when justified for large
>projects), and MAKE take care of this for me. If constants or fixed
>references change so often that I need to recompile the entire project too
>often, maybe these values SHOULD be variables.
My MAKE's handle this just fine and the speed of current
computers makes linktime symbolics not so necessary, of course.
But the ability to define the physical locations of memory
mapped hardware without having to create variable storage to do
so, is still missing from C.
>Your second example is excellent. One could examine the assembly output from
>the compiler to do this so it IS possible but counting instruction cycles
>and making adjustments is far easier to do directly in assembler.
Far easier. And it doesn't need to be "maintained" everytime a
compiler changes its optimizations or a different switch option
is selected for compilation.
>Couldn't your third example be done with pointers in C? Wouldn't it be even
>more readable and easy to manage? Maybe I don't understand the example.
No. Think more deeply about the problem and ask some questions,
then. I think you'll get the point on your own, but if you
don't, I'll be happy to elaborate.
>Jonathan, we had better be careful. This is sci.electronics.design. We are
>going to get kicked off of here and sent to comp.arch.embedded!!
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup