Problem with delay loop

[Royce Pereira]

Hi, David,

On Wed, 03 Oct 2007 02:24:16 +0530, David Kelly <dkelly@...> 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
> want.

If you're interested, I've reverted back to the older compiler version.

>
>> Of course, there's no disputing that. But the delay loop is just an
>> example, of how simple ,intuitive code can throw the compiler into a
>> tizzy.
>
> Avr-gcc *has* a delay loop that the compiler recognizes and leaves
> alone. You've been told about <util/delay_basic.h> yet you have written
> more email than the amount of code you would have to change to use it.

Read again the lines preceding your comment. It's not just about a delay loop.

My 'problem' triggered a discussion 37 posts long (so far). Of which mine were just 6 (including the one that triggered the discussion). So the fact that 'I wrote more email than code' is incorrect.

I may be stupid & stll 'learning' as compared to other older members(who I highly respect), but, I beleive I'm entitled to politely express my opinion.

It's true I had a different understanding of compiler working (which others have made efforts to correct).

Does this deserve a attack from you at a personal level?

Cheers,
--Royce.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-6]

Royce Pereira wrote:

> Hi,
>
> On Mon, 01 Oct 2007 13:02:32 +0530, David Brown
> <david_brown@...> 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 that's the way it is.  The compiler
>> only has to generate code that has the same effect as the source
>> you've written, and a simple "ret" has that effect.
>
> Why then was the empty 'ret' function retained?

If the function is globally visible (i.e., not static to the file), then
the compiler must generate a working function - "ret" is as small and
fast as it gets.

> 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 make a difference in
> size/speed of the code.
>

The compiler will inline calls to the function in the same translation
unit, and thus eliminate the "ret".

> (Instead, the compiler destroys a perfectly good delay loop I've used
> for the last 2 years -yes, I'm still sore)
>
>> There is no way in C to express the idea of a time delay - the
>> language has no concept of time. Thus you have to go out of your
>> way to tell the compiler to be particularly stupid if you want this
>> sort of code to work.  There are other ways to get a delay, such as
>> the library routines or hardware timers, or by including something
>> like an "asm volatile ("nop")" in the loop, but using a volatile
>> loop counter is an easy way to get an approximate delay loop.
>>
> Of course, there's no disputing that. But the delay loop is just an
> example, of how simple ,intuitive code can throw the compiler into a
> tizzy. I've used SDCC(for mcs51) where the compiler 'recognises' code
> patterns, and says "Oh, I know what this is - it's a delay loop! -
> Let it pass."(for example).
>

That sounds to me like a very bad idea, as you'll find out the day you
write a slightly unusual delay loop which is not pattern matched, and
your code gets eliminated.

> I've always maintained -  good software is one that does what you
> *want* it to do, *not* what you tell it to do. ;)
>

I prefer software to do as I tell it, but perhaps to warn me if that's
not what it thinks I mean.  Thus gcc will accept code like "if (a = 1)
...", but will warn that it's probably not what I meant.  Of course, it
would all be a lot easier if the language in question had a way to
express what I want!

> Regards, --Royce.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Paulo Marques]

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 removed entirely.

This is even better with "new and improved compilers": even if you don't
declare the function static, but you compile your project with "-combine
-fwhole-program", the compiler can still through it away entirely :)

For instance, I have a small project with several c modules, that when
compiled with "-combine -fwhole-program" creates a 3kb .text section. If
I place a "return 0" at the top of main, the compiler optimizes almost
everything away and produces a 180 bytes .text section. Only the
interrupt handlers survive, because we told the compiler explicitly not
to through them away.

Note that I'm not advocating for not declaring static functions that
should be static. Only that functions that can't be static because are
used from outside its module can still be optimized by the compiler with
this option.

The only downside is that this basically makes the compiler compile the
entire project at once instead of just the modules with changes. For
small projects, this isn't too bad at all, and for big projects you can
do it for just the "final version".

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: [phone], Fax: [phone]
Web: www.grupopie.com

"All I ask is a chance to prove that money can't make me happy."



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list