avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: C vs. assembly performance


From: David Brown
Subject: [avr-gcc-list] Re: C vs. assembly performance
Date: Sun, 01 Mar 2009 20:55:20 +0100
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

Georg-Johann Lay wrote:
David Brown schrieb:
variable names "tmp16", "tmp32" and "tmpS16" are truly awful. It is also (usually) best to declare such temporaries in as small a block as possible. Thus they should not be at the start of the function, but instead make your cases like this:

{// (N * 0.75) - 40    DB41        -40 to +150 °C
    int16_t temp = (int16_t)(KLineFrameM1[41]) * 3 / 4 - 40;
    var_format_S16(buff, temp, 0);
    break;
}
That will give clearer code and let the optimiser be more flexible in its register choices.

As far as "the optimizer" of gcc is concerned, that makes no difference. It knows exactly what register contains what value and is aware of the place where a register "dies", i.e. the register can be reused for whatever other stuff. Anyway, even if just one temp variabe is used, gcc will produce a new (pseudo) register vor every result like moves, arithmetic, etc. These pseudos may or may not end up in the same macine register. On that level, blocks are just syntactic sugar (if they are not used to hide visibility, e.g. like in int tmp=0; {int tmp = 1;} )


I haven't looked at code generated for such switches (there is often so much of it), so I admit to having guessed a little. I was thinking especially of when you have debug information enabled - that can force the compiler to keep variables in separate registers.

To get a notion of the various machine intependant transformations, have a glance at gcc's output with -fdump-tree-all, and for the machine dependent it is -fdump-rtl all. They make clear that do-while, while, for and if-goto are just flavours of same sugar.


And here was me thinking the generated source code was sometimes a bit big to wade through... Sometime I must look at this in more detail.

mvh.,

David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]