Programming memes

[SiliconWizard]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Well, -O0 more or less disables all optimizations, as it allows for exact debugging.
With -O0, every C line should translate to some object code to allow stepping through the whole code while debugging. So this is expected.

Starting with -O1, this kind of trivial-to-optimize code is reasonably optimized. Higher level of optimizations may make use of specific target instructions, but on very simple targets, that may not make a difference (again for trivial code such as this, more complex code may benefit from many kinds of additional optimizations). Function parameters may also be passed as registers instead of using the stack.

[nuno]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Should be able to produce comparable results on -Os or -O3 though.

I always compile to AVR with -Os, it produces good results. -O3 applies more aggressive (and space hungry) speed optimization techniques such as loop unroling, but the AVR core is already fast.

In general, relevant space can be saved with only these 3 techniques:

• Declare with static all variables and functions not needed in other files.
• In functions where volatile variables are accessed more than 1 or 2 times, copy them to local variables at entry, manipulate local variables and copy them back to the volatiles at the end (typically interrupts... mind the mutual exclusion access).
• Declare main as int __attribute__((noreturn)) main () .

If very tight on space and can't/don't want to move to a bigger flash chip, GCC can sometimes be oriented to produce a smaller code by rearranging parts of the flow structure - the .LST file is our best friend when optimizing very aggressively.

[NorthGuy]

There's some terrible code there, but the good news is modern compilers are pretty good.

That's where compilers shine - optimizing "terrible" code. But nobody writes code like this. Thus, real world optimizations aren't equally impressive.

[brucehoult]

There's some terrible code there, but the good news is modern compilers are pretty good.

That's where compilers shine - optimizing "terrible" code. But nobody writes code like this. Thus, real world optimizations aren't equally impressive.

When programs write code it's often pretty horrible. I haven't looked too hard but verilator is likely to be an example. It's main sin that I know of is making functions waaaaay too long.