Dave Hansen wrote:
[...]
I don't remember the code. Was the function declared static? If not,
the compiler must generate at least the ret since functions external to
the file could potentially call it as well. If the function was static,
the code for it (and the calls to it) could indeed be
Royce Pereira wrote:
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
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
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
> 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,
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
> 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
http://lists.nongnu.org/mailm
> -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 sec
> -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
> -Original Message-
> From: John Regehr [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 01, 2007 10:59 PM
> To: Eric Weddington
> Cc: 'Paulo Marques'; 'David Brown'; 'AVR-GCC'
> Subject: RE: [avr-gcc-list] Problem with delay loop
>
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 a
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
variable
> 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
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 o
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 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
>
>
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 "v
"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
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 c
> -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
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
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
volatil
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
AVR-GCC-list@nongnu.
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 modifyi
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 variable
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 t
On Fri, Sep 28, 2007 at 11:26:43PM +0530, Royce Pereira wrote:
> Hi all,
>
> OK fine I agree.
>
> we have to use 'volatile' and all.
>
> But why must it generate such horrid code...
There are those here who would tell you that any calibrated delay loop
is horrible code.
The stack has to be pro
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):
//-
> 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 PR
On Fri, Sep 28, 2007 at 09:05:40AM -0500, David Kelly wrote:
>
> For finer delays don't forget the OCR functions on the timers. Is pretty
> easy to write and create very accurate delays with:
>
> void delay( uint8_t delay );
> {
> OCR2A = TCNT2 + delay;
> TIFR2 = (1<
> // wait
On Fri, Sep 28, 2007 at 01:29:19PM +0530, Royce Pereira wrote:
> 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;
> }
> //=
> -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
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 "loc
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
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
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
>
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 newer
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 varia
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;
}
//
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 n
42 matches
Mail list logo
