article - Guidelines for writing efficient C code

D

Default User

Martin said:
Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
programming language.

Guideline #2: Ignore anyone who thinks that guidelines for code
written in C and guidelines for code written in C++ should be similar.

It should be noted that the article concerns writing code for embedded
applications and is heavily geared towards that, not general
programming. It's written by a guy from Green Hills, probably NOT the
person who posted this link. As it says there:

"This article is excerpted from a paper of the same name presented at
the Embedded Systems Conference Silicon Valley 2006. Used with
permission of the Embedded Systems Conference."



Brian
 
S

Skarmander

Marco said:
FYI:

Guidelines for writing efficient C/C++ code

http://www.embedded.com/showArticle.jhtml?articleID=184417272

any comments?
"Conclusion

The performance impact of some decisions that programmers make when writing
their code can be significant. While efficient algorithmic design is of the
highest importance, making intelligent choices when implementing the design
can help application code perform at its highest potential."

Paragraphs like these inspire a deep admiration in me for the richness and
vast potential of written language in communication, and an equally deep
sadness for how easily this is squandered.

The rest of the article is worthless (as opposed to vacuous); anyone who
understands the reasoning behind these guidelines does not need them, and
anyone who does not should not be put in a situation where they could apply
them. Obviously, however, this is not factoring in reality, which is rather
boring and depressing, and left as an exercise to the reader.

On a less cynical note, I like tea. Unfortunately that has nothing to do
with the article, but you can't have everything.

S.
 
C

Chris Hills

Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
programming language.

Guideline #2: Ignore anyone who thinks that guidelines for code written
in C and guidelines for code written in C++ should be similar.

I agree completely!

There are three languages, C, C++ and "c/C++" :)

The point is C++ was based on C90. After that point C went one way (C99)
and C++ diverged in a different direction.

There are parts of C99 that do not behave the same way as the C90 that
was used in C++.
 
I

Ian Collins

Martin said:
Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
programming language.
:)

Guideline #2: Ignore anyone who thinks that guidelines for code written
in C and guidelines for code written in C++ should be similar.
There's plenty of overlaps at the low levels this paper uses.
 
C

Chris Hills

Skarmander said:
I like it very much. Especially the typos in identifiers. You don't see
those often enough in guidelines.

A nice exercise is to find statements in those guidelines that are not
*completely* false. I think I saw a few.

S.

Oh Bugger! Let me know and I will have them replaced with suitable urban
myths.

I am currently working on MIStRAy C:2004 :)
 
P

pete

I'm also of the opinion that one shouldn't use
types of lower rank than int, without a special reason.
I was going to mention it to a recent poster
who posted a function definition with unsigned short
(or something like ushort, I don't exactly remember)
parameters, but I never got around to it.
 
C

Charles Krug

FYI:

Guidelines for writing efficient C/C++ code

http://www.embedded.com/showArticle.jhtml?articleID=184417272

any comments?

Embedded systems is NOT general programming and shouldn't be confused
with it.

When you need to get "close to the machine," all bets are off, and you
start needing to worry about things like the exact bit width of a data
type, including unpacked vs packed structures, how good your compiler's
optimizer is, (or in some cases if it works at all).

This is a Particular problem domain, that Happens often to use C, and
occasionally c++, when it's not using Assembly.

What it discusses is only "On Topic" in as much at it uses the
constructs of Standard c which, being embedded code, need not be very
"standard" at all.
 
C

Chris Hills

I'm also of the opinion that one shouldn't use
types of lower rank than int, without a special reason.[/QUOTE]


Well, on all 8 bit micros you have to. Usually char on account of the
fact they often don't have [any/many] 16 bit registers and the Char is
really the native size for the part. Signed and unsigned char, of course
are integer types.
I was going to mention it to a recent poster
who posted a function definition with unsigned short

I don't like using shorts unless they are a real in that is between Int
and char. They should nt be used where they are the same size as char or
int.
 
C

Chris Hills

Charles Krug said:
Embedded systems is NOT general programming and shouldn't be confused
with it.

I agree. The number of people I see doing "IT" on embedded systems is
getting worse.

However "standard c" is rarely used these days. 95% of all C programming
is going to use some extensions and deviations. From windows to Linux to
the vast array of embedded systems.
 
K

Keith Thompson

Chris Hills said:
writes [...]
I'm also of the opinion that one shouldn't use
types of lower rank than int, without a special reason.


Well, on all 8 bit micros you have to. Usually char on account of the
fact they often don't have [any/many] 16 bit registers and the Char is
really the native size for the part. Signed and unsigned char, of course
are integer types.

Which, of course, qualifies as a "special reason".
 
D

Dave Vandervies

Chris Hills said:
However "standard c" is rarely used these days. 95% of all C programming
is going to use some extensions and deviations. From windows to Linux to
the vast array of embedded systems.

``95% of all C programs'' I would be willing to believe, but a similarly
large randomly chosen percentage of most of those programs can be written
in standard C, with only the interface to whatever system-specific
functionality is needed using extensions and deviations.

I would say (making a guess at what might be a real number, rather than
using rectal extraction to obtain an impressively large one) that probably
75% of C code can/should be written in such a way that it would do The
Right Thing when compiled with any sensible conforming compiler[1],
even if it isn't done that way in practice.


dave
(unless you're competing with WeBuildRadar, then tie it to the system
as closely as you can, whether there's a good reason or not)

[1] Which is a slightly stronger condition than "is strictly conforming",
but not by too much.
 
M

Michael Mair

Chris said:
It should be back up now. Week end maintenance :-(

Great! It's hilarious and terrifyingly realistic at the same
time...

[The following is not meant as serious guideline]

However, you managed to not sufficiently un-restrict people's
creativity in some points:

I suggest more rules on (ab)using bit operations, e.g.
- XOR swapping for efficiency
- & and | to emulate non-shorcircuited logic operations
- using bit operations whenever you can -- they are always faster

In addition, a programmer should expand his or her horizon and
abilities by making arbitrary impromptu tests like "let's see
whether I can write this function/module without using directives
x, y, z and operators a, b, c".

switch followed by a compound statement gives room for
optimizations like restricting the scope of auxiliary variables
to this statement only, on-the-fly Duff's Device like partial
loop unrolling etc.

The obvious lack of mentioning gets() for the case of "knowing
thy input" may even be seen as malicious neglect.


Cheers ;-)
Michael
 
C

Chris Hills

Michael Mair said:
Great! It's hilarious and terrifyingly realistic at the same
time...

Thanks.

I wrote the initial parts during an idle half hour in a MISRA C meeting.
That is why it has 127 rules that mirror the MISRA rules.

Next on my agenda is MIStRAy-c:2004 to mirror the MISRA-C:2004 but at
the moment we are working on the TC and example suite.
 
D

Dave Vandervies

[Most] C code can/should be written in such a way that it would do The
Right Thing when compiled with any sensible conforming compiler[1],
[1] Which is a slightly stronger condition than "is strictly conforming",
but not by too much.

I think I meant ``slightly weaker condition'' here, not stronger.


dave
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top