Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
EW
PostPosted: May 26, 2011 - 02:16 AM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

Ok, I've decided.

I'm going to continue WinAVR.

I would like to come out with a release say in the next 3 months (or less, if I can swing it).

It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

Joerg has mentioned a new avrdude and avarice release as well, but realize that his time is spread thin across multiple projects.

We have to work out what version of avr-gcc to include and what kinds of patches it needs to contain. There's a number of bug fixes that need to be done.

I'm sure there will updates on other tools as well.

Bug reports, patches, and constructive feedback welcome. And help on any of the projects is always welcome too.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
alank2
PostPosted: May 26, 2011 - 03:07 AM
Posting Freak


Joined: Jul 16, 2009
Posts: 1832


Hi EW,

Awesome news!! Thanks for your hard work!

Alan
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: May 26, 2011 - 04:58 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22847
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Does this mean then that this will just work with Studio 4.xx?

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
EW
PostPosted: May 26, 2011 - 05:38 AM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

It works the other way around. The IDE has to be built such that it works with any installed toolchain. I'm not in control of the IDE portion.

_________________
Eric Weddington
www.linkedin.com/in/ericweddington/
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
ka7ehk
PostPosted: May 26, 2011 - 05:54 AM
10k+ Postman


Joined: Nov 22, 2002
Posts: 14097
Location: Tangent, OR, USA

If you need any help (with documentation, what ever), please shout, scream, or otherwise pull my chain. Not much experience, but It is something I ought to be able to help with.

Jim

_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA

There are some answers that have no questions.
 
 View user's profile Send private message  
Reply with quote Back to top
JohanEkdahl
PostPosted: May 26, 2011 - 07:13 AM
10k+ Postman


Joined: Mar 27, 2002
Posts: 22307
Location: Lund, Sweden

Good news, Eric!
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
wek
PostPosted: May 26, 2011 - 08:12 AM
Raving lunatic


Joined: Dec 16, 2005
Posts: 3219
Location: Bratislava, Slovakia

Looking forward to it.

Jan
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
clawson
PostPosted: May 26, 2011 - 09:24 AM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71915
Location: (using avr-gcc in) Finchingfield, Essex, England

Great news. "Toolchain" was starting to look a lot like a half baked lame duck.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
SprinterSB
PostPosted: May 26, 2011 - 12:59 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1744
Location: Saar-Lor-Lux

EW wrote:
I'm going to continue WinAVR.


Hi Eric, that's very good news! What base version?

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).


Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.


What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers. There have been two nomanclatures in avr-libc:

Numenclatur of avr-libc with SIG_ prefix.

Names that occured in any target manual, suffixed _vect. If a vect is renamed in the handbook because of some update, new versions of avr-libc should NOT remove the old name but still support it. For example some handlers are named TIM0_* and others TIMER0_*.

If some name ever existed, it should persist to do so.

There are already enough barriers useres have to cope with, so I do not understand yet another, pure artificial barrier.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
EW
PostPosted: May 26, 2011 - 02:03 PM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

SprinterSB wrote:
EW wrote:
I'm going to continue WinAVR.


Hi Eric, that's very good news! What base version?


Good question. I don't have an immediate answer on that. This is one of the main things that we need to look into in order to do the release. I know that there are issues in GCC 4.5.x, 4.6.x, and trunk (future 4.7). We need to figure out which version and which set of patches to include. Very likely some bugs need to be fixed before a release.

SprinterSB wrote:

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).


Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.


Certainly we need to go through the bug list and address issues like those. There has been work done recently by Georg-Johann Lay on various bug reports, which has been very much appreciated.

SprinterSB wrote:

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.


What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers.


Technically, the SIG_* names have been deprecated for years. The *_vect names have been preferred. We've been slowly moving to those names over time, mainly because they are compatible with IAR. If you have noticed, new device support does NOT contain the old SIG_* ISR naming.

What we have not had in avr-libc in the past, is an easy way to tell the user what is deprecated and what is not. With the upcoming 1.8.0, these old deprecated names are now "poisoned" so that if they are used in an application the compiler will generate an error. However, the good thing with our deprecation system is that any user can easily get to the deprecated names just by defining an identifier before including io.h and then all of the deprecations are immediately available without warnings or errors.

The point of deprecations is that they eventually will go away. We try to give ample warnings to the end user so they have time to change their applications to any new system. Please realize that we are actually very conscientious about keeping old names around for a long time. We are keenly aware about backwards compatibility. But in the end, those SIG_* names are outdated, and they are not used across all devices. The *_vect names are used across all devices.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
sternst
PostPosted: May 26, 2011 - 02:34 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2728
Location: Osnabrueck, Germany

EW wrote:
There has been work done recently by Georg-Johann Lay on various bug reports,
[whisper] SprinterSB IS Georg-Johann Lay Wink [/whisper]

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
EW
PostPosted: May 26, 2011 - 03:15 PM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

sternst wrote:
EW wrote:
There has been work done recently by Georg-Johann Lay on various bug reports,
[whisper] SprinterSB IS Georg-Johann Lay Wink [/whisper]


<smacks forehead really hard> See? Even I can't keep track of all the people and their handles! Rolling Eyes

Well then let me just add that I'm also going to see what can be done internally to get these bugs fixed.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
SprinterSB
PostPosted: May 26, 2011 - 04:21 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1744
Location: Saar-Lor-Lux

EW wrote:
SprinterSB wrote:
What base version?
Good question. I don't have an immediate answer on that. This is one of the main things that we need to look into in order to do the release. I know that there are issues in GCC 4.5.x, 4.6.x, and trunk (future 4.7). We need to figure out which version and which set of patches to include. Very likely some bugs need to be fixed before a release.

  • PR46779/45291/41894: Wrong code in some rare cases. Evil.
    http://www.avrfreaks.net/index.php?name ... p;t=107000
  • PR48459: breaks DWARF in 4.6 and 4.7. Maybe Eric B. can have a look?
  • PR46278: Code bloat that might be unacceptable. This is still in 4.7 (but with reduced severity), see also
    http://www.avrfreaks.net/index.php?name ... p;t=106531
  • PR45263: Minor issue, easy to port
  • PR34734: Annoying. In C, DECL_INITIAL is available, but in C++ it is empty even if there is an initializer. (presumably because of different FE).

    Maybe avr-libc could take care of that by conditionally definig PROGMEM as section attribute for C++?
Besides that, the ABI needs to be updated

  • The ABI should state what the compiler can/will handle concerned SFRs like RAMP* and EIND. If the user has to fiddle with that, the ABI should say that. Ditto if or if not pro/epilogue saves them or not. It should be stated if these regs might be undefined in main or startup should restore reset value (PR44940).
  • ABI has to be adaped to actual avr-gcc behaviour for return type promotion as discussed recently and which is de-facto ABI since 4.3.
  • ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
dl8dtl
PostPosted: May 26, 2011 - 04:42 PM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7376
Location: Dresden, Germany

> ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

Curious: where is it being used?

I remember the old FP library using it, but that should be gone now.

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
clawson
PostPosted: May 26, 2011 - 04:44 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71915
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Curious: where is it being used?

I thought I'd read it was used inside printf()? Maybe that info is "out of date" these days? (or maybe I remembered wrong?)

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
EW
PostPosted: May 26, 2011 - 05:05 PM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

Yeah, the priority is always
- Fix wrong code bugs first
- Optimization bugs later.

SprinterSB wrote:
[list]
[*]PR46779/45291/41894: Wrong code in some rare cases. Evil.
http://www.avrfreaks.net/index.php?name ... p;t=107000


If it's wrong code, it should be fixed.

SprinterSB wrote:
[list]
[*]PR48459: breaks DWARF in 4.6 and 4.7. Maybe Eric B. can have a look?


I've let our internal team know about this. But it needs to be made a priority.

SprinterSB wrote:
[list]
[*]PR46278: Code bloat that might be unacceptable. This is still in 4.7 (but with reduced severity), see also
http://www.avrfreaks.net/index.php?name ... p;t=106531


Code bloat is still lower priority (compared to wrong code).

SprinterSB wrote:
[list]
[*]PR45263: Minor issue, easy to port


If it's low-hanging fruit, then we should see about getting it done.

SprinterSB wrote:

  • PR34734: Annoying. In C, DECL_INITIAL is available, but in C++ it is empty even if there is an initializer. (presumably because of different FE).
    Maybe avr-libc could take care of that by conditionally definig PROGMEM as section attribute for C++?



Yeah, overall I would like to see more of the C++ issues get fixed. If it's easier to do the fix in avr-libc, then let's get it done.


SprinterSB wrote:
[list]
Besides that, the ABI needs to be updated

  • The ABI should state what the compiler can/will handle concerned SFRs like RAMP* and EIND. If the user has to fiddle with that, the ABI should say that. Ditto if or if not pro/epilogue saves them or not. It should be stated if these regs might be undefined in main or startup should restore reset value (PR44940).
  • ABI has to be adaped to actual avr-gcc behaviour for return type promotion as discussed recently and which is de-facto ABI since 4.3.
  • ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.


ABI changes are much bigger and long-term. I don't think that this should be done for a WinAVR release but we need to make sure all the developers are on the same page for any changes.

...And sorry for not knowing your username here on Freaks. *cough* Embarassed
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
SprinterSB
PostPosted: May 26, 2011 - 05:10 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1744
Location: Saar-Lor-Lux

dl8dtl wrote:
> ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

Curious: where is it being used?

abs(float), -float, to setup shift counter, &~(1<<const), |(1<<const), =(1<< const), ... with high register pressure i.e. stuff that ends up in l-regs.

Just look for bld in
http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
dl8dtl
PostPosted: May 26, 2011 - 05:13 PM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7376
Location: Dresden, Germany

> Just look for bld in
> http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup
> http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup

Hmm. Things nobody ever told us about we could not document in
the avr-libc documentation ...

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
EW
PostPosted: May 26, 2011 - 06:19 PM
Raving lunatic


Joined: Mar 01, 2001
Posts: 5011
Location: Rocky Mountains

TFrancuz wrote:
And please, remember about Bug c++/43745 – it is really annoying to have vtables in SRAM:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745


I haven't forgotten, however technically that is an enhancement. It's going to have lower priority than a wrong-code bug.

The goal is to get this out in 3 months or less. We have limited resources, so we have to prioritize the issues. The more help there is, the more we can address.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
mckeemj
PostPosted: May 27, 2011 - 01:00 AM
Resident


Joined: Jun 26, 2006
Posts: 852
Location: San Luis Valley, Colorado ( 2,318m )

I haven't played around in the GCC internals sandbox yet but I'd be happy to help in any way possible.

Martin Jay McKee

_________________
As with most things in engineering, the answer is an unabashed, "It depends."
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits