| Author |
Message |
|
|
 Posted: May 26, 2011 - 02:16 AM |
|
Joined: Mar 01, 2001
Posts: 4953
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. |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 03:07 AM |
|
Joined: Jul 16, 2009
Posts: 1579
|
|
Hi EW,
Awesome news!! Thanks for your hard work!
Alan |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 04:58 AM |
|
Joined: Mar 28, 2001
Posts: 20347
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
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 05:38 AM |
|
Joined: Mar 01, 2001
Posts: 4953
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
Marketing Manager
Open Source & Community
Atmel
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 05:54 AM |
|
Joined: Nov 22, 2002
Posts: 12041
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
"The only thing standing between us and victory is defeat" P.G.Wodhouse in Wooster & Jeeves series
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 07:13 AM |
|
Joined: Mar 27, 2002
Posts: 18545
Location: Lund, Sweden
|
|
|
|
|
|
|
|
Posted: May 26, 2011 - 08:12 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
Looking forward to it.
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 09:24 AM |
|
Joined: Jul 18, 2005
Posts: 62277
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Great news. "Toolchain" was starting to look a lot like a half baked lame duck. |
_________________
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 12:59 PM |
|
Joined: Dec 21, 2006
Posts: 1483
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. |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 02:03 PM |
|
Joined: Mar 01, 2001
Posts: 4953
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. |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 02:34 PM |
|
Joined: Jul 23, 2001
Posts: 2438
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  [/whisper] |
_________________
Stefan Ernst
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 03:15 PM |
|
Joined: Mar 01, 2001
Posts: 4953
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 [/whisper]
<smacks forehead really hard> See? Even I can't keep track of all the people and their handles! 
Well then let me just add that I'm also going to see what can be done internally to get these bugs fixed. |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 04:21 PM |
|
Joined: Dec 21, 2006
Posts: 1483
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.
|
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 04:42 PM |
|
Joined: Dec 20, 2002
Posts: 7276
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.
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 04:44 PM |
|
Joined: Jul 18, 2005
Posts: 62277
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?) |
_________________
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 05:05 PM |
|
Joined: Mar 01, 2001
Posts: 4953
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*  |
|
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 05:10 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
|
|
|
|
|
Posted: May 26, 2011 - 05:13 PM |
|
Joined: Dec 20, 2002
Posts: 7276
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.
|
| |
|
|
|
|
|
|
Posted: May 26, 2011 - 06:19 PM |
|
Joined: Mar 01, 2001
Posts: 4953
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. |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 01:00 AM |
|
Joined: Jun 26, 2006
Posts: 625
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."
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
