Paulo Marques wrote:
David Brown wrote:
Paulo Marques wrote:
David Brown wrote:
[...]
it could perhaps reason that since there is no way for anything
outside the program to find out where the local volatile variable
resides, there is no way for anything else to influence or use the
Graham Davies wrote:
Eric Weddington wrote:
... We were discussing the possibility of the compiler being
smarter about 'volatile' and local automatic variables. I would
definitely say that if the local variable's address is taken, then
all bets are off.
Second point first. If the address of
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Tuesday, October 02, 2007 2:48 AM
To: 'AVR-GCC-LIST'
Subject: Re: [avr-gcc-list] Problem with delay loop
Graham Davies wrote:
Eric Weddington wrote:
... We were
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Graham Davies
Sent: Monday, October 01, 2007 6:56 PM
To: 'AVR-GCC-LIST'
Subject: Re: [avr-gcc-list] Problem with delay loop
First point second. I think I agree with you about
Ah, ok then. In practice, I have never needed to use setjmp/longjmp, so I
have a tendency to forget about these routines.
We should all be so lucky :).
John Regehr
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
Hi,
On Mon, 01 Oct 2007 13:02:32 +0530, David Brown [EMAIL PROTECTED] wrote:
Royce Pereira wrote:
So I have to write more 'C' code :) to get the same stuff done, in
the 'new smarter' compiler! Interesting.
Doesn't seem right, some how.
Regards, --Royce.
It might not seem right, but
From: [EMAIL PROTECTED]
Hi,
On Mon, 01 Oct 2007 13:02:32 +0530, David Brown [EMAIL PROTECTED] wrote:
Royce Pereira wrote:
So I have to write more 'C' code :) to get the same stuff done, in
the 'new smarter' compiler! Interesting.
Doesn't seem right, some how.
Regards,
On Wed, Oct 03, 2007 at 12:23:46AM +0530, Royce Pereira wrote:
Why then was the empty 'ret' function retained?
I would think such a case would be the prime candidate for
optimisation. The compiler should eliminate such a funtion, as well
as all calls to that function. That would really
Hi, David,
On Wed, 03 Oct 2007 02:24:16 +0530, David Kelly [EMAIL PROTECTED] wrote:
So? Why did *you* change compilers if the old one did what you wanted?
If it doesn't do what you want then its your choice whether to change
your code to conform or to revert to the compiler that did what you
There are good reasons for much of the stuff produced by the use of
volatile - since the local variable is volatile, it has to be put on
the stack. Generating a stack frame on the AVR needs a bit of messing
around in the prologue and epilogue, including turning off interrupts
while
David Brown wrote (in part):
... since the local variable is volatile,
it has to be put on the stack.
I don't see how that follows (if it is declared automatic and is of local
scope).
Graham.
___
AVR-GCC-list mailing list
Graham Davies wrote:
David Brown wrote (in part):
... since the local variable is volatile,
it has to be put on the stack.
I don't see how that follows (if it is declared automatic and is of
local scope).
Graham.
It would be more correct to say that since the local variable is
David Brown wrote:
[...]
it could perhaps reason
that since there is no way for anything outside the program to find out
where the local volatile variable resides, there is no way for anything
else to influence or use the variable, and therefore the volatile
qualifier can be ignored.
This
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Paulo Marques
Sent: Monday, October 01, 2007 7:35 AM
To: David Brown
Cc: 'AVR-GCC'
Subject: Re: [avr-gcc-list] Problem with delay loop
David Brown wrote:
[...]
it could perhaps reason
Paulo Marques wrote:
David Brown wrote:
[...]
it could perhaps reason that since there is no way for anything
outside the program to find out where the local volatile variable
resides, there is no way for anything else to influence or use the
variable, and therefore the volatile qualifier
Eric Weddington wrote:
...
I agree with the statement above that 'volatile' is precisely to warn the
compiler that it should not 'reason' anything about [the] variable.
However, David brings up a good point. A local variable is put on the stack,
generally not the place for hardware to
David Brown wrote:
Paulo Marques wrote:
David Brown wrote:
[...]
it could perhaps reason that since there is no way for anything
outside the program to find out where the local volatile variable
resides, there is no way for anything else to influence or use the
variable, and therefore the
-Original Message-
From: Preston Wilson [mailto:[EMAIL PROTECTED]
Sent: Monday, October 01, 2007 8:13 AM
To: Eric Weddington; 'Paulo Marques'; 'David Brown'
Cc: AVR-GCC-LIST
Subject: Re: [avr-gcc-list] Problem with delay loop
Eric Weddington wrote:
...
I agree
Eric Weddington wrote:
... We were discussing the possibility of the
compiler being smarter about 'volatile' and
local automatic variables. I would definitely
say that if the local variable's address is taken,
then all bets are off.
Second point first. If the address of a variable is taken
On Monday 01 October 2007 09:48:23 am Eric Weddington wrote:
Its an interesting question. I'm not sure what the answer is. Perhaps a
language lawyer on comp.lang.c could explain the reasoning behind the
current standard.
http://thread.gmane.org/gmane.linux.kernel/523210
for the Linux view on
However, David brings up a good point. A local variable is put on the stack,
generally not the place for hardware to modify the variable. And generally,
other parts of the program (such as ISRs) don't have access to the specific
location of the variable on the stack. Both hardware and ISRs
Hi all,
In the latest WinAVR (avr-gcc (GCC) 4.1.2 (WinAVR 20070525) I found this.
Check this out:
//==
void delay(unsigned del_cnt)
{
while(del_cnt--);
return;
}
//===
Compiles as (from the .lss file):
//===
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Friday, September 28, 2007 3:17 AM
To: AVR-GCC
Subject: Re: [avr-gcc-list] Problem with delay loop
This is probably in the FAQ somewhere - if not, it should be!
I checked
I think we are discussing not the solution :-)
The compiler optimizes unused code away, that is OK!
If we use a volatile, the WRITE ACCESS could not longer be optimized and
also a new READ ACCESS before subtraction must! be done. That is what
the compiler do, that is also OK!
If there is a
Royce Pereira wrote:
So I have to write more 'C' code :) to get the same
stuff done, in the 'new smarter' compiler!
Not more code, just correct code.
Have you tried returning the final value of your delay argument from the
function? If the compiler optimizes only within the boundaries of
Please use optimizer! Something like -O2 -O3 -Os ... as you need!
Simplify your delay loop:
void delay(volatile word cnt) { ...
Have fun!
Royce Pereira schrieb:
Hi,
On Fri, 28 Sep 2007 14:47:26 +0530, David Brown [EMAIL PROTECTED] wrote:
This is probably in the FAQ somewhere - if not, it
Hi,
On Fri, 28 Sep 2007 14:47:26 +0530, David Brown [EMAIL PROTECTED] wrote:
This is probably in the FAQ somewhere - if not, it should be!
The compiler is smart enough to figure out that your delay function does
no useful work - thus the optimiser does not generate any code. This is
Hi,
On Fri, 28 Sep 2007 14:47:26 +0530, David Brown [EMAIL PROTECTED] wrote:
This is probably in the FAQ somewhere - if not, it should be!
The compiler is smart enough to figure out that your delay function does
no useful work - thus the optimiser does not generate any code. This is
Hi,
On Fri, 28 Sep 2007 13:42:18 +0530, Klaus Rudolph [EMAIL PROTECTED] wrote:
The code has been optimized. Well done!
If you need the variable access use 'volatile'
Why does it get optimised?
I understand the meaning of 'volatile', but why is it required here ?
It is clear that the variable
Royce Pereira schreef:
Hi all,
In the latest WinAVR (avr-gcc (GCC) 4.1.2 (WinAVR 20070525) I found this.
Check this out:
//==
void delay(unsigned del_cnt)
{
while(del_cnt--);
return;
}
//===
Well writing your own delay_loops is
The code has been optimized. Well done!
If you need the variable access use 'volatile'
Hi all,
In the latest WinAVR (avr-gcc (GCC) 4.1.2 (WinAVR 20070525) I found this.
Check this out:
//==
void delay(unsigned del_cnt)
{
while(del_cnt--);
return;
}
This is probably in the FAQ somewhere - if not, it should be!
The compiler is smart enough to figure out that your delay function does
no useful work - thus the optimiser does not generate any code. This is
correct compilation - it's your code that is wrong. The difference is
that the
Date: Fri, 28 Sep 2007 14:21:38 +0530 To: [EMAIL PROTECTED] Subject: Re:
[avr-gcc-list] Problem with delay loop From: [EMAIL PROTECTED] CC:
AVR-GCC-list@nongnu.org Hi, On Fri, 28 Sep 2007 13:42:18 +0530, Klaus
Rudolph [EMAIL PROTECTED] wrote: The code has been optimized. Well
done
Hi Klaus,
On Fri, 28 Sep 2007 14:57:14 +0530, Klaus Rudolph [EMAIL PROTECTED] wrote:
Please use optimizer! Something like -O2 -O3 -Os ... as you need!
My makefile already has
OPT = s
Simplify your delay loop:
void delay(volatile word cnt) { ...
Already tried that. No change.
If it's
Hi all,
OK fine I agree.
we have to use 'volatile' and all.
But why must it generate such horrid code...
(I reproduce the comparison again below to get the *real* issue into focus)
The compiler output with the 'correct' code ('volatile' used):
David Kelly wrote:
... because it was volatile it *had* to
be fetched and stored each time.
Oh boy. That's a really interesting statement (to me anyway, but I have a
volatile fetish). You're saying that having chosen to put the variable in
memory, the compiler is obliged to fetch it prior
On Sep 28, 2007, at 8:58 PM, Graham Davies wrote:
David Kelly wrote:
... because it was volatile it *had* to
be fetched and stored each time.
Oh boy. That's a really interesting statement (to me anyway, but I
have a volatile fetish). You're saying that having chosen to put
the
37 matches
Mail list logo
