Codesize Optimisation Tips

[andyturk]

Works quite well for Linux kernel.

Yep, Linus has been pretty definite in his assessment of C++.     

On the other hand, both GCC and LLVM are written in C++, and the backstory on GCC moving from C to C++ is interesting.

The real issue for mcu-based projects is the atrocious awfulness of most embedded code. And you're right, it's not about the language, it's about the lack of abstraction, the copied-and-pasted garbage that moves from project to project and the fact that too many embedded programmers don't understand the code they're working on.

[hamster_nz]

Random Optimization Hint #2
For 'simple' functions (e.g to check the range of a value), sometimes it is better to use a "#define func(x)  ...." rather than "int func(int x)".

e.g.

Code: [Select]

int is_digit( char c) {
  return (c >= '0' && c <= '9');
}

vs:

Code: [Select]

#define is_digit(x)  ((x) >= '0' && (x) <= '9')


This is not very smart.
First of all, all macros should be uppercase. In this case IS_DIGIT(x).
Second, if you replace functions by macros, you loose type check. This is very dangerous and often leads to problems. In the first example of yours, when you call is_digit(myvar) and myvar is not char, you get a warning during build. In case of the second example, you get nothing. Of course, some macros will always work but some give you headache.

Do you have a citation for "all macros should be upper case"? (yes, I agree, but I can't find it written anywhere.. it is more a convention than a hard rule)

And you missed the greatest example of why you shouldn't use macros with careful understanding of how you intend to use them....

Code: [Select]

  x = is_digit(getchar());

gets expand to:

Code: [Select]

x = ((getchar()) >= '0' && (getchar()) <= '9');

So getchar() gets called twice... that is a very strong reason as to why you should avoid them where possible.

[Siwastaja]

Yep, Linus has been pretty definite in his assessment of C++.     

He has some fair points.

In a small software project with one or maybe two developers, they can effectively limit theirselves on which C++ features they use. If one is experienced enough in developing in C++, the results are most likely good, sometimes even nice, elegant and powerful.

However, in a project like linux kernel, requiring huge number of people and requiring certain low-level mindset, writing it in C++ would most likely result in a huge amount of code that's total crap. Designing the OO class models and the object crap around it and maintaining it while the reality around changes would prevent the required low-level work. OO requires careful planning and a powerful crystal ball, which is why the large multi-module projects often fail.

From this viewpoint, it isn't only a language difference; it's social difference: in large C projects, people are more experienced in low-level; in large C++ projects, people, unless very carefully hand-picked, tend to be "fresh out of computer science lessons" mindset, and face a language which is very complex under the hood.

The reason I never became a good C++ programmer is because the nature of my projects has been somewhat similar to what the linux kernel faces: most of the time things work out very well without needing any of the nice features C++ provides. Because of the combination of me not needing it, and it being complex and difficult, I can't write good C++ and probably never will. The difference is, I'm not claiming to be a capable C++ programmer like many mediocre C++ programmers are.

[Kjelt]

Does anyone else have any tricks to share that the compiler might not optimise?
Cheers, Brek.

Sure, in one of my previous jobs I had an 8 bit target with 8KB Rom and 1kB Ram and a table of about 300 bytes for the power over time run up. So we needed to keep time and follow the table otherwise boom 
We ran out of Rom so I put the table in excel made a X Y point graphic and let Excel calculate a second or third order polynome to approach the graph.
Then I implemented the simple polynome in three locs and saved over 240 bytes 
Does not always work but many tables can be calculated with an aproximation algorithm.

Two cons :
- a real catch is the extra time to calculate over a table lookup, so when I set the power setpoint I already calculated the new one in front.
- my colleagues did not get it, when the table changed for a different product I had to do it again although I documented it properly and added the excel to the repo. So for R&D where the table might change each day due to the overhead it is not well suited.

Sometimes you need to split the table to get two or more simple polynomes instead of one complex one.

[andyturk]

From this viewpoint, it isn't only a language difference; it's social difference: in large C projects, people are more experienced in low-level; in large C++ projects, people, unless very carefully hand-picked, tend to be "fresh out of computer science lessons" mindset, and face a language which is very complex under the hood.

That's a great point.

C++ is often taught as a "high level" language, but if you try to apply many of those "high level" idioms directly to an embedded project, you'll create a mess (even if you're using the idiom as intended). So it takes some experience or guidance to use the extra power safely. Metaphorically, if you're a woodworking teacher and have to decide whether to use a bandsaw or hand tools for the next class project, it comes down to how capable your students are.

I've had the good fortune to work on projects with small firmware teams (1-3 engineers), where it was possible to keep coding standards high and directly interact with everyone. Using version control and pull requests for *everything* makes it possible to head off mistakes before they get too far, but also lets less experienced engineers see how APIs should be used (and how even project leads sometimes write buggy code  ).

[phil from seattle]

At some point you have to realise plain C isn't the best tool for any programming job.

Works quite well for Linux kernel.

I think the language doesn't matter. What matters is vision, design, algorithms. Once you have this all in place, you can use assembler, you can use C, you can write in C++, or anything else you want. Moreover, when you have a good design, it's quite obvious that the language you use doesn't have any practical significance.

+1000.  Though there are some exceptions.  Like BASIC...

[Siwastaja]

C++ is often taught as a "high level" language, but if you try to apply many of those "high level" idioms directly to an embedded project, you'll create a mess

C++ is, of course, not really a "high level" language (unless by "high level" we mean pretty much anything beyond assembly, something even C would fit into). This is pretty basic knowledge and even most heavy C++ users, even advocates have no issue admitting this. That's also a strength, if you look at it that way.

Anyone who teaches C++ as a "high level" language has no freaking clue what they are talking about, but CS teachers in universities are often utterly clueless - I have seen it happen.

I think the language doesn't matter. What matters is vision, design, algorithms. Once you have this all in place, you can use assembler, you can use C, you can write in C++, or anything else you want. Moreover, when you have a good design, it's quite obvious that the language you use doesn't have any practical significance.

I can't agree with the "language doesn't matter" mentality. Yes, it's all fine and dandy "don't fight guys" thing trying to prevent a lurking language war from escalating, but please be honest with yourself - of course choosing the programming language (which is almost always much more than just a language: environment, toolset, libraries, "frameworks", and more often than most care to admit - also the team!) matters. It's a massive implementation and project management detail, and these details do matter. Sometimes there are several equally good options, but sometimes not really.

[nctnico]

At some point you have to realise plain C isn't the best tool for any programming job.

Works quite well for Linux kernel.

If you have ever worked on the Linux kernel you'd wish they converted it to C++. Sometimes the creator of something becomes an anchor. Let's leave it at that.

I think the language doesn't matter. What matters is vision, design, algorithms. Once you have this all in place, you can use assembler, you can use C, you can write in C++, or anything else you want. Moreover, when you have a good design, it's quite obvious that the language you use doesn't have any practical significance.

Sure the language matters. One of the problems with C and in a lesser extend with C++ is that you have to do a lot of leg work like keeping track of pointers and there is no real support for complex data types. All in all that means less productivity compared to languages which allow you to focus more on functionality and less on OS and hardware related stuff.