bug in avr-lib _delay_func. ?

Go To Last Post
33 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im using AVRstudio 4.18sp3 with avr8bit tool-chain , My controller is ATTINY-85(20)

Standard _delay_ms function is here

_delay_ms(double __ms)
{
	uint16_t __ticks;
	double __tmp = ((F_CPU) / 4e3) * __ms;
#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__)
	extern void __builtin_avr_delay_cycles(unsigned long);
	__builtin_avr_delay_cycles(__tmp);
#else
	if (__tmp < 1.0)
		__ticks = 1;
	else if (__tmp > 65535)
	{
		//	__ticks = requested delay in 1/10 ms
		__ticks = (uint16_t) (__ms * 10.0);
		while(__ticks)
		{
			// wait 1/10 ms
			_delay_loop_2(((F_CPU) / 4e3) / 10);
			__ticks --;
		}
		return;
	}
	else
		__ticks = (uint16_t)__tmp;
	_delay_loop_2(__ticks);
#endif
}

My Program its basic blink led:

#include 
#include 

F_CPU = 6000000UL

int main()
{


    DDRB = _BV(PB0);
    while ( 1 )
    {
        PORTB |= _BV(PB0);
        _delay_ms(10);
		PORTB &= ~_BV(PB0);
		_delay_ms(10);
    }
} 

im using avr studio 4.18 sp3.

My problem is too strange. Normally , I expect to see 20ms on output-pin . But i measure output-pin with scope , one period is (5 ms) . and then try to investigate problem , and finally i found strange command in delay.h

 	double __tmp = ((F_CPU) / 4e3) * __ms;

why the F_CPU frequency divide by 4 on the code.

PS:
I double-check my fuse-bits, I do no set any pre-scaler on fuse-bits.

Can someone explain this problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
why the F_CPU frequency divide by 4 on the code.

Well, first of all :
4e3 = 4 x 10^3 = 4000

It's not "dividing the frequency", it's calculating a number of cycles to iterate to generate a requested delay. The fact that you spotted a 4 in there, and your results are of by a factor of 4 is pure coincidence.

These functions are used by many people, there's no bug in there. Most likely you have not correctly set the fuse-bits.

How are they currently configured ? What programmer and software are you using ?

edit:

F_CPU = 6000000UL 

Aren't you getting a compilation error or at least a warning on that ?
What you probably wanted there is

#define F_CPU 6000000UL 

notice no equals sign and no semicolon.

But when using AVRStudio, don't (re-)define it in a source file, but enter it in the "Project Options" under "Frequency", that way it will be passed as a commandline-switch on compilation of every file.
I believe you will get a warning if you redefine it in a source file.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have a 6Mhz crystal attached? How are you getting a 6Mhz clock? If you do have the crystal did you program the fuses in the Tiny85 to use an external crystal?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:
Do you have a 6Mhz crystal attached? How are you getting a 6Mhz clock? If you do have the crystal did you program the fuses in the Tiny85 to use an external crystal?

Im using external clock. it is 6 MHZ.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Im using external clock. it is 6 MHZ

So what are the CKSEL fuses set to? And what is CKDIV8 set to?

Or to put it simply, what are the values for the low/high fuse bytes?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
why the F_CPU frequency divide by 4 on the code.

Well, first of all :
4e3 = 4 x 10^3 = 4000

Quote:

It's not "dividing the frequency", it's calculating a number of cycles to iterate to generate a requested delay. The fact that you spotted a 4 in there, and your results are of by a factor of 4 is pure coincidence.

Yes I point (4) and , delay_us use (3) , so why are
they using these factor ? can Someone explain ?

void
_delay_us(double __us)
{
	uint8_t __ticks;
	double __tmp = ((F_CPU) / 3e6) * __us;
#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__)
	extern void __builtin_avr_delay_cycles(unsigned long);
	__builtin_avr_delay_cycles(__tmp);
#else
	if (__tmp < 1.0)
		__ticks = 1;
	else if (__tmp > 255)
	{
		_delay_ms(__us / 1000.0);
		return;
	}
	else
		__ticks = (uint8_t)__tmp;
	_delay_loop_1(__ticks);
#endif
}

Finally :

I edit these codes and remove these numbers "(4) from delay_ms" and (3) from delay_us" and everything works great, so i want to understand , why these numbers are using?

Quote:

How are they currently configured ? What programmer and software are you using ?

Programmer: JTAG-ICE. I also said , im using Avr-toolchain with avr studio 4 sp3.

Quote:

F_CPU = 6000000UL 

Aren't you getting a compilation error or at least a warning on that ?
What you probably wanted there is

#define F_CPU 6000000UL 

notice no equals sign and no semicolon.

This is typo error , its not big deal.

Quote:

But when using AVRStudio, don't (re-)define it in a source file, but enter it in the "Project Options" under "Frequency", that way it will be passed as a commandline-switch on compilation of every file.
I believe you will get a warning if you redefine it in a source file.

I also did that, and same results.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do know, don't you, that "AVR Toolchain" rather than "WinAVR" has a SERIOUS bug in its delay.h ? Set the #define that stops it trying to use _builtin_cycles() and it will then work as expected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson , Last three years i always use AVR32 compiler and cpu's. but i have little project in my hand, yesterday i had install avr studio 4.18 with service pack, and saw new toolchain on the ATMEL site , i want to try. actually this is my first attempt using atmel avr tool-chain . i will remove it immediately and back to winavr after your words.

#define that you talking about , its beginning on the delay.h , its automatically choose builtin_cycles.

Honestly , im waiting like that answer, just i wanna make sure , i am wrong or not.

I know this is not a place about talking compiler , but i have one question in my mind , which toolchain is more power-full? if you have time can you please little explain ?

Thanks a lot.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

i want to try

Well while Atmel continue to flush out the bugs in what is clearly "beta" code you are far better off downloading/installing "WinAVR" which is proven and pretty stable.

But to continue using the "AVR Toolchain" then looking at the source:

http://svn.savannah.nongnu.org/v...

it seems that if, you:

#define __DELAY_BACKWARD_COMPATIBLE__

then the old style (working) code will be used.

Quote:
but i have one question in my mind , which toolchain is more power-full?

Well even if I had the first idea what you meant by "powerful" I'll bet your interpretation of the word and mine would differ. But if you are talking about a C popularity contest then my personal ranking would be:

1) avr-gcc
2) CodeVision
3) IAR
4) Rowley
5) Imagecraft
6) MikroC

But everyone you ask will have a different order and different reasons. There might even be people who think MikroC is a good compiler!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> You do know, don't you, that "AVR Toolchain" rather than "WinAVR" has
> a SERIOUS bug in its delay.h ?

Curious, is this an avr-libc bug? I haven't seen a bug report for it...
It's been me who introduced the original support for __builtin_avr_delay_cycles
(that's why I'm asking ;). The idea is that using this function, the compiler
knows the exact effort it costs to setup the delay.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
which toolchain is more power-full?

Some sort of answer to that is here: https://www.avrfreaks.net/index.p...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Curious, is this an avr-libc bug? I haven't seen a bug report for it...

Is this a bug report?

https://savannah.nongnu.org/bugs/index.php?30363

Are there really patches now ?

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
> You do know, don't you, that "AVR Toolchain" rather than "WinAVR" has
> a SERIOUS bug in its delay.h ?

Curious, is this an avr-libc bug? I haven't seen a bug report for it...
It's been me who introduced the original support for __builtin_avr_delay_cycles
(that's why I'm asking ;). The idea is that using this function, the compiler
knows the exact effort it costs to setup the delay.

You have to kidding right? Am I missing the humor?
If not, There has been much discussion about this
in several threads on freaks.
Here is one: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=95328
I even filled in a bug report on savannah back in July
https://savannah.nongnu.org/bugs/index.php?30363
And I think you even commented on the bug report when it was first posted.

Anitha's update/patch looks like solves all the known issues including providing for better resolution, rounding options, and even a backward compatibly mode.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I somehow completely missed the original (and genuine) bug caused
by this. The bug report was filed while I've been on vacation (and that's
probably also been the time the avrfreaks discussion took place), so I
didn't (want to) spend too much time into Internet things. As the report
also mentioned so many other things beyond the actual bug (which could be
taken as "missed optimization" rather than true bugs), I just picked up
those in the discussion.

So sorry, Cliff, don't blame the guys at Atmel about the bug, it's been me
who introduced it. :<0 (Actually, it's been Atmel who eventually repaired
my breakage, namely Anitha.)

I guess it's time to add something to the testsuite to ensure this won't
happen again.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So sorry, Cliff, don't blame the guys at Atmel about the bug, it's been me
who introduced it

No problems. (you do work for Atmel though don't you? ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:
which toolchain is more power-full?

Some sort of answer to that is here: https://www.avrfreaks.net/index.p...

Thanks , John

I know , that question is not meaning-full.and it doesn't have clear answer. I guess i couldnt tell my self correctly , I meant to which one is more stable. Actually Cliff answered my meaningless question correctly :) .

So , when i faced that type bug(i'm not sure its my mistake or not.) but i need forgiveness from you guys . because i didn't use any 8bit compiler last three years. My customer need little application on ATTINY 85. that time , i had download 8-bit compiler from ATMEL site.(it should be more stable then others. if you are chip provider(This is totaly my thought)).

But the biggest problem is , why The Atmel doesn't have patch files on their site. i can swear,
"BACKWARD_COMPABILITY or something like that , or another information about delay calculation" isn't included in the library that i downloaded from ATMEL site. also today , i re-check Atmel site. and i didn't see any patch or patches ATMEL Tools Download page for 8 bit compiler. Still , Atmel Download page has buggy version of the library.

Just Think like that, if you are beginner of programming ATMEL chips. Logically , you will download all application from ATmel site. and some how you need delay function, you are in big trouble if you don't have scope or any measurement instrument in your hand, You cant find the problem easily. That time you hold rights to blame directly ATMEL and choose another chip maker.

So, Atmel has to inform customer about bug or bugs in their site. or give link to "savannah" site.

Thanks all ,and apologize to all of you , "I didn't google it before writing my first question"

Mehmet

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Memhet,

This was simply a mistake on Atmel's part (on Jörg's part in fact). We all make mistakes. The only problem here is that while it was spotted that appears to have slid under the razor wire and not been acted upon. Hopefully Atmel might consider withdrawing the "AVR Toolchain" link from their website until this has been corrected now? That way people such as yourself would then just naturally download WinAVR instead which has no such problem.

At the very least I'd hope that Atmel might add a note to the "AVR Toolchain" download link to say "If you intend to use the delay functions contained herein then make the define __DELAY_BACKWARD_COMPATIBLE__"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't believe the comment about __DELAY_BACKWARD_COMPATIBLE__ is correct if you happen
to have the broken delay.h code.
I believe what you will really want to do is:

#define  __HAS_DELAY_CYCLES 0

This will disable the code that uses the builtin gcc delay function which
incorrectly/accidentally miscalculated the number of delay cycles.

That said,
I'm not sure what actual code is currently part of the AVR Toolchain vs what is in WinAVR,
but in looking directly at the AVR libC SVN tree, the broken version of delay.h.in is rev: 2103 the next
revision of delay.h.in is 2189

Revision 2189 contains the updates that Anitha and I discussed in the Savannah bug report.
The code in 2189 slightly modifies the behavior (we both thought for the better). But in an
attempt to provide 100% backward compatibility at least in the near term for those
very odd cases where it is needed, the define
__DELAY_BACKWARD_COMPATIBLE__ was created.
(normally this should not be needed)

It is a catch 22. The ifdef/define __DELAY_BACKWARD_COMPATIBLE__ is only available in version 2189, but 2189 should not need to use it since
the delay cycle calculation should be correct in that version.

It is only version 2103 that has the issue, and to fix
that one __HAS_DELAY_CYCLES should be set to 0.

But if you always set __HAS_DELAY_CYCLES to 0 then you
lose out on the newer/better delay code in version 2189
once that becomes available.

It is a bit of mess.

As an alternative, users that have delay problems could switch to the delay_x project for their delay functions (100% API compatible to delay.h) until this gets resolved:
https://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=665&item_type=project

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should suffice to just replace the util/delay.h file by the new version.
Bingo600 suggested I post that file here so everybody stands a chance to
"upgrade" their library to the fixed version, as a stop-gap measure until
avr-libc 1.7.1 will have been released.

Note that the attached file assumes an installation that uses a compiler
offering the __builtin_avr_delay_cycles function.

Attachment(s): 

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a note to the above file.

The doc in the file says this

Quote:

User can define __DELAY_BACKWARD_COMPATIBLE__ to get a backward compatible delay
although this will be deprecated in future.

To get 100% backwards compatibility , add the below line.

#define  __DELAY_BACKWARD_COMPATIBLE__

Edit: Btw ... Thanx Jörg

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The new code has better granularity and offers more accurate delays than the original code as well as offering options on which way to round the delay cycles.
I wouldn't think that any new nor the vast majority of existing code would need to use the backward compatibility
mode.

The idea behind the backward compatibility ifdef/define was that if you had existing code that failed to function properly with the newer code that there was a option to revert to the original bahavior that used the basic delay loops with its larger granularity,and rounding
delay cycles down to the nearest increment of that larger granularity (except at the very low end where the delay is rounded up to 1 increment of the granularity).

It was assumed that this previous behavior would seldom be needed and so that is why it is not default behavior in the new code.
i.e. provide better functionality by default but yet provide a backward compatibility mode where it is needed.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And thanks again to Bill, for all his ideas and contributions. I'm
a little sorry I missed the actual (and serious) bug back in July,
because the discussion between Bill and Anitha quickly went on
about details of how to improve the rounding behaviour.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
>It's been me who introduced the original support for __builtin_avr_delay_cycles.

Hi Jörg, or anybody that knows,
How do I know if the/my version of the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?
I got WinAVR-20100110(to use it with Studio 4) so I'd think whoever packaged it knows what support is or not in the compiler; but I don't know how to find out...
I'd like to know if my max is 768 us / F_CPU or 4294967.295 us / F_CPU, and the documentation says:
Quote:
If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.

Thanks,
Cat

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

WinAVR-20100110

That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif


Just for the record:

avr-gcc has built-in macros to query for availability of built-in functions:
6.54.4 AVR Built-in Functions
This applies to avr-gcc from FSF repo, I cannot say how other avr-gcc distribution allow to identify these features.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

WinAVR-20100110

That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif

Let's clarify this: WinAVR 20100110 has the __builtin_avr_delay_cycles() function available. However, does not use this builtin for the 20100110 version of WinAVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Let's clarify this: WinAVR 20100110 has the __builtin_avr_delay_cycles() function available. However, does not use this builtin for the 20100110 version of WinAVR.

Thank you everybody;
Does this mean that if I replace the "delay.h" I got in "WinAVR 20100110" with the one that Jörg posted earlier in the thread I can have long AND (relatively) precise microsecond delays?
Thanks,
Cat

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
clawson wrote:
That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

#ifndef __HAS_DELAY_CYCLES
#define __HAS_DELAY_CYCLES 1
#endif


Just for the record:

avr-gcc has built-in macros to query for availability of built-in functions:
6.54.4 AVR Built-in Functions
This applies to avr-gcc from FSF repo, I cannot say how other avr-gcc distribution allow to identify these features.

While it's been a couple of years a a few gcc versions back since I looked and tracked this down, from what I remember this is not always the case.

From what I remember, many of the various versions were doing this as a convention but it was not done by gcc itself for all versions.
In other words the various ports were calling the function to create an internal compiler define when they created a built-in function.
So for example, ports like the MIPS compiler were very good about creating a define for every built in function but other architectures were not as diligent and that was the problem.
In the case of the AVR version, as I recall some of the AVR built-ins didn't create the corresponding define and hence didn't have any way of being detected by the preprocessor. And that was the problem.

The real solution would be to fix gcc at a higher level to always create the define when a built in function was created. That way, every version of gcc could automagically benefit from it rather than depending on each version of gcc to do it.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:
SprinterSB wrote:
avr-gcc has built-in macros to query for availability of built-in functions:
6.54.4 AVR Built-in Functions
This applies to avr-gcc from FSF repo, I cannot say how other avr-gcc distribution allow to identify these features.

In the case of the AVR version, as I recall some of the AVR built-ins didn't create the corresponding define and hence didn't have any way of being detected by the preprocessor. And that was the problem.

Then the built-in support was not based on an official release and added by hand (presumably WInAVR or Atmel ports). I know it because I committed the avr built-in stuff (with some minor changes) to FSF repo and care for a corresponding macro alongside each built-in.

I guess it's quite tedious or merely impossible for avr-libc resp. it's maintainers to detect if a specific version comes with a built-in or not without these macros. The only way would be to check at configure time against link fails.

IMO the easiest for avr-libc is to query the "official" macros, and for each private port that adds built-ins by patch to add built-in defines following the same nomenclature.

Quote:
The real solution would be to fix gcc at a higher level to always create the define when a built in function was created. That way, every version of gcc could automagically benefit from it rather than depending on each version of gcc to do it.

NACK. Most things there are historical, one port might define a macro or not, an other port might define it to 0 or 1, a third port might define it to the built-in function's name.

Ports like rs6000 (aka. PowerPC) have ~1000 built-ins, some private ports even 50% more. I makes more sense to group the built-ins and supply one macro for a group, e.g. if built-ins just map to machine instructions that are only available on specific derivatives/HW extensions.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:

IMO the easiest for avr-libc is to query the "official" macros, and for each private port that adds built-ins by patch to add built-in defines following the same nomenclature.

Quote:
The real solution would be to fix gcc at a higher level to always create the define when a built in function was created. That way, every version of gcc could automagically benefit from it rather than depending on each version of gcc to do it.

NACK. Most things there are historical, one port might define a macro or not, an other port might define it to 0 or 1, a third port might define it to the built-in function's name.

Ports like rs6000 (aka. PowerPC) have ~1000 built-ins, some private ports even 50% more. I makes more sense to group the built-ins and supply one macro for a group, e.g. if built-ins just map to machine instructions that are only available on specific derivatives/HW extensions.

I was specifically referring to built in compiler functions that traditionally have __builtin prefixes.

The problem with leaving it up to developers to create a corresponding macro is that as we have seen it sometimes does not get done.
i.e. in the AVR version when __builtin_avr_delay_cyclcles() showed up there was no corresponding c preprocessor define. This made it impossible to have common code in a libc header that automatically adjusted itself depending on the compilers capabilities.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:
I was specifically referring to built in compiler functions that traditionally have __builtin prefixes.

There are >= 1000 __builtin-prfixed builtins in PowerPC because all target (and most front end) built-ins are prefixed __builtin_.

Quote:
The problem with leaving it up to developers to create a corresponding macro is that as we have seen it sometimes does not get done.
i.e. in the AVR version when __builtin_avr_delay_cyclcles() showed up there was no corresponding c preprocessor define. This made it impossible to have common code in a libc header that automatically adjusted itself depending on the compilers capabilities.

It works the other way round: If the macro is not there (__BUILTIN_AVR_DELAY_CYCLES) then the built-in function is not present. The converse is not necessarily true and you might miss some occasion where the built-in is actually there. But it's save.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:

It works the other way round: If the macro is not there (__BUILTIN_AVR_DELAY_CYCLES) then the built-in function is not present. The converse is not necessarily true and you might miss some occasion where the built-in is actually there. But it's save.

Huh? I Did not follow that sentence at all.
I think you have it backwards.

Currently, if you have a __BUILTIN* macro define, you know the
builtin function exists. However, if you don't have it , you know nothing because the built in function might or might not exist.

The problem is that a builtin function can exist and there is no way to detect its existence to allow a library to deal with different versions of the compiler.
To me that is a very real problem because it
depends on the compiler developers to properly insert/create macros when creating new builtin functions.
And while it technically not a compiler bug, it does potentially make it very difficult if not impossible for library writers to write code that can automatically maintain backward compatibility yet take advantage of newer compiler capabilities.
That is why (IMHO) it is better to have the macros created automagically by the compiler.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:
Currently, if you have a __BUILTIN* macro define, you know the builtin function exists. However, if you don't have it, you know nothing because the built in function might or might not exist.

Yes, that's what I tried to express. No native speaker me.

bperrybap wrote:
The problem is that a builtin function can exist and there is no way to detect its existence to allow a library to deal with different versions of the compiler.

To me that is a very real problem because it depends on the compiler developers to properly insert/create macros when creating new builtin functions.

And while it technically not a compiler bug, it does potentially make it very difficult if not impossible for library writers to write code that can automatically maintain backward compatibility yet take advantage of newer compiler capabilities.

That is why (IMHO) it is better to have the macros created automagically by the compiler.


I agree that it's simpler that way for the user, and that's exactly the reason why I introduced such macros for avr-gcc mainline.

As far as GCC as a whole is concerned, you will still have to struggle with versions < 4.7 because it would be a new feature. There was just a bit work on the builtins framework to just initialize a builtin structure if a source actually requests that builtin. It's an optimization to safe some resources when building because you don't have to instantiate thousands of built-ins if most of them are never used. So with automatic built-in macro there's maybe a chicken-egg problem in GCC with code like

#ifdef __BUILTIN_FOO
foo()
{
  __builtin_foo();
}
#endif

But I don't know anything about the inerts of built-in machinery; you will have to switch over to gcc@gcc.gnu.org mailing list to discuss technical details or if you want so supply a patch to enhance GCC. GCC development is currently in stage 1, i.e. open for new feature. So head for GCC :-)

avrfreaks does not support Opera. Profile inactive.