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

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

RE: [avr-gcc-list] Help, Compiler ignores some part of the function!


From: MuRaT KaRaDeNiZ
Subject: RE: [avr-gcc-list] Help, Compiler ignores some part of the function!
Date: Sat, 3 Dec 2005 12:46:35 +0200

Hello,

Thanks for the help. As you stated, the compiler was optimizing and
removing that section of the code.
I'll consider your additional comments on coding style & posting.

I'm compiling with -Wall, but no warning appears for the local variable
"controller", that it is not utilized properly.


Regards

Murat Karadeniz
http://www.onlinefavbar.com/mukas



-----Original Message-----
From: Daniel O'Connor [mailto:address@hidden 
Sent: Saturday, December 03, 2005 6:15 AM
To: address@hidden
Cc: MuRaT KaRaDeNiZ
Subject: Re: [avr-gcc-list] Help, Compiler ignores some part of the
function!


On Sat, 3 Dec 2005 08:50, MuRaT KaRaDeNiZ wrote:
> Using WinAVR-20050214, I try to compile the following function, but 
> the section between [BOOKMARK1] and [BOOKMARK2] does not get compiled 
> without any error indication. İ checked the routine in the .lst file, 
> this section is not compiled to assembly. The rest is there. What is 
> wrong?

It is being optimised away.
The variable 'controller' has no effect because the last line of the
function is commented out.

Also, the formatting is fairly hard to read. A good convention is to
make #defines all upper case so that you can easily distinguish them.

The preprocessor supports #else too, so you should probably do stuff
like..

#ifdef USE_INTERNAL_ENCODER_CONSTS //destinationVertical given in angles
at the final moving axis ErrorVertical = error = ( DestinationVertical /
enc1_constant ) - encoder; #else //destinationVertical given in encoder
ticks at the motor encoder for the same final motion ErrorVertical =
error = DestinationVertical - encoder; 
#endif

If you are going to paste code and error messages and your email client
insists on wrapping them, please send them as attachments. That way they
are _much_ easier to read.

Another style issue - if your function takes no arguments you should 
declare it like..

void Foo(void)
{
..
}

Some indenting makes things [a lot] easier to read, eg..
if (foo) {
    abc;
    def;
} else {
    bar;
    baz;
}

If you wish to comment out a block of code it is safer to use '#if 0' as

you don't get any problems with nested comments.

I'm not sure if you're compiling with -Wall, but that is almost always 
a good idea as the compiler will usually tell you when you make mistakes
even if it feels like it's being too picky :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C





reply via email to

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