Re: [avr-gcc-list] Compiler optimisation and volatile variables

[David Brown]

----- Original Message -----
From: "Willem Jacobus Marais" <address@hidden>
To: <address@hidden>; "Rob Prowel" <address@hidden>;
<address@hidden>
Sent: Friday, February 03, 2006 10:21 AM
Subject: Re: [avr-gcc-list] Compiler optimisation and volatile variables


> On Fri, 2006-02-03 at 09:31 +0100, David Brown wrote:
> > You are introducing several layers of extra uncertainty -
> > your assembly, your assumptions about compiler-assembly interfacing,
> > and the
> > reliability and maintainability of mixing the two languages.
>
> How often does the way the compiler handle structs and array change? If
> these remain constant (with the C type sizes) throughout the compiler
> releases, the compiler-assembly interfacing would remain safe.
>
> If the statement I have made is incorrect, please do tell. At the moment
> I can't think of any compiler-assembly interfacing uncertainties.
>


I doubt that structs and arrays change in practice - however, there are
certainly no guarentees about that.  For example, if you have a file-static
struct which is never sent outside the module (by pointers), and contains a
member which is never used, the compiler could optomise it out.  In fact,
with the new optomisations in gcc 4.1 and program-at-once compilation, the
compiler could take the global struct, split it into bits and hold different
bits in different registers at different times, without ever having the
complete struct in memory.

What I was really referring to was a common practice for hand-optomised
assembly where you first compile the C code and look at the generated
assembly.  Then you write your assembly code to "fit in", using the
registers picked by the C compiler.  Of course, the correct way to do it
involves either writing a separate function that follows the specified
calling conventions (and thereby having the function call overhead), or
using inline assembly with gcc's very powerful and flexible syntax.  But
that is a demanding job, and only worth doing on occasion (or for commonly
used library code).

Either way, if you are adding hand-optomised code, you are either making
unwarrented assumptions about the compiler-generated code, or you are
restricting the compiler by forcing it to follow conventions rather than
optomise the code better, or you are writing such a mess of gcc inline
assembly code that you certainly can't call it "safe" without a great deal
of work.

mvh.,

David