FYI, the avr backend of GCC (avr-gcc, avr-g++) has been deprecated for v10, release schedule spring 2020.
If the backend is not re-written to use a different scheme to model condition-code, it will be removed from GCC in v11, release schedule spring 2021.
Does this mean anything in a practical sense?
Is GCC support slowly going away (or becoming lower priority) for AVR's?
I suspect Microchip would like me to buy their compiler instead (and give me a 50% off coupon).
Does this mean anything in a practical sense?
This relates to gcc v10. Given that Microchip is still using gcc v5, it would probably take 10 years or more before anyone notices anything.
Anyway, I noticed that code quality has peaked for v8 (when the ISR fix was added), v9 seems to produce worse code. It seems recent gcc improvements are deleterious for AVR targets, so I predict v10 will be even worse.
Is GCC support slowly going away (or becoming lower priority) for AVR's?
Would ones at Microchip expense for some of that effort?
(Microchip direct or indirect effort for source code modifications, FSF AVR GCC community effort to reach release)
Compiler Tool Chain Development – Embecosm
...
How much will a tool chain cost to develop?
...
For most architectures, Embecosm are able to create a proof-of-concept functional tool chain in 3 engineer months.
...
due to the Embench vice chair is at Embecosm :
Contributors to embench/embench-iot · GitHub
Our Participation in the Open Source AVR® Community - YouTube (Microchip Technology, 2m36s)
Embench™: A Modern Embedded Benchmark Suite
FYI, the avr backend of GCC (avr-gcc, avr-g++) has been deprecated for v10, release schedule spring 2020.
If the backend is not re-written to use a different scheme to model condition-code, it will be removed from GCC in v11, release schedule spring 2021.
Forgive me for asking a stupid question, but does this mean there will be no more AVR support after GCC v9.x?
Technically, the removal will likely be carried out right after v10 will have been released, which is in less than 1/2 a year from now.
So how hard will it be for the AVR folk to keep v10 updating chasing various OS changes (assuming we don't care much about the back end.)
Arduino is now shipping gcc 7.4 to try to deal with the latest "64bit only) MacOS (or they're trying to, anyway.)
If you read the documents the deprecation will be avoided if someone implements the requested changes. Any chance the Atmel folks would do this?
There are two ways of representing the condition codes in the back-end for an architecture: the old-fashioned, deprecated way called CC0 representation and the modern, mandatory for new back-ends, way called MODE_CC representation. As of now, most back-ends have been converted to the MODE_CC representation, but a few of them still use the CC0 representation, as summarized in Status of supported architectures.
chasing various OS changes
It is also about chasing the C/C++ standards, and what if some other language is added.
Wonder what "Arduino will do" ...
I suppose a commercial compiler won't "Cut" there .. Maybe they have to switch to the "handicapped" version w. bad optimization.
Interesting ....
/Bingo
If you read the documents the deprecation will be avoided if someone implements the requested changes. Any chance the Atmel folks would do this?
There are two ways of representing the condition codes in the back-end for an architecture: the old-fashioned, deprecated way called CC0 representation and the modern, mandatory for new back-ends, way called MODE_CC representation. As of now, most back-ends have been converted to the MODE_CC representation, but a few of them still use the CC0 representation, as summarized in Status of supported architectures.
Currently the condition code is implicitly clobbered by almost anything.
Most of the inline assembly I've seen does not include cc as a clobber.
If it does arithmetic, it clobbers cc, i.e. SREG.
Also, my recollection is that the ABI does not explicitly state whether function calls can clobber cc.
An obvious solution is to have both inline assembly and function calls implicitly clobber cc.
It is also about chasing the C/C++ standards
Meh. I doubt whether most AVR embedded programmers are that much about new features ("current" avr-gcc is already ~4 major gcc versions behind, and I don't see a huge clamor for updates. People are still using 2010 WinAVR...) The people trying to do legacy hardware support "but xyz tool was W95 and doesn't run on anything newer than XP and I found the source but it won't even compile on a modern system and ..." seem more common.
The one place where "old compiler" may start to matter is when in 2026 they start making Arduinos with the as yet unannounced ATWhizzMegaSuper12345 and the compiler can't support it.
the as yet unannounced ATWhizzMegaSuper12345
Nicknamed the AVR O-Mega.
Inline asm would be by far the easiest of all problems. Just implement the target_asm_clobbers hook.
.
Maybe it's time to let avr-gcc walk the walk of all mortals. At least that would save me some spare time because then I would no more be tempted to improve it.
There is a bounty now on BountySource for the cc0 -> CCmode conversion:
.
Wow, if they managed it for the 68K, surely the prospects for AVR are promising...
$85 in less than a day.
The 68K bugzillla was created a little over two months ago:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
... and appears to be resolved.
The bounty reached $5000 after little more than a month, and hit a little more than $6000 before being closed.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
The bounty is up to $315.
The bounty is up to $535.
Th 68k changes are pretty massive :-(
Bounty is at $565, increasing by $1per day.
With that speed, it will surpass the 68k bounty in about 13 years...
Does anyone know whether someone converted MSP430? That might be a closer example than the 68k.
The bounty is up to $1470.
I admit I have started reading the GCC Internals Manual. The entire manual is about 800 pages.
(I'm making no commitment to work on this or claim that I am qualified to do so.)
status: I can now build gcc for avr from checked-out git repo. I have yet to figure out how to run an uninstalled gcc.
bounty increased to $2020
I have read through a good amount of the GCC internals document and spent a little time going through avr.md.
The existing code seems to use attributes for clobbering cc.
;; '*' because it is not used in rtl generation.
(define_insn "*reload_inpsi"
[(set (match_operand:PSI 0 "register_operand" "=r")
(match_operand:PSI 1 "immediate_operand" "i"))
(clobber (match_operand:QI 2 "register_operand" "=&d"))]
"reload_completed"
{
return avr_out_reload_inpsi (operands, operands[2], NULL);
}
[(set_attr "length" "6")
(set_attr "adjust_len" "reload_in24")
(set_attr "cc" "clobber")])
bounty is time-limited :
The top bounty is from the CEO of SparkFun Electronics
15 Years of SparkFun - News - SparkFun Electronics
bounty is time-limited :
I believe they recanted the two year policy. Not sure what the prior one was.
Hi
You're receiving this because we updated our Terms of Service.
Withdrawal of new Terms of Service
Yesterday, we communicated a change to the Bountysource Terms of Service (ToS) agreement.
These changes have been withdrawn and the ToS reverted to its prior state.
The ToS will be revised and clarified in the future.
Thankyou
Bountysource Team
That's funny, I just stumbled upon this thread today and only hours ago Microchip added $5000 to the bounty (now at $7,150)
I hope that will speed up the conversion to MODE_CC
Yeah it's a decent amount now, but still, I'm sure not many people actually know how to do it.
Yeah it's a decent amount now, but still, I'm sure not many people actually know how to do it.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Yeah it's a decent amount now, but still, I'm sure not many people actually know how to do it.
You don't actually get the full amount in cash when you claim a bounty. They take a 10% fee.
It's still enough to at least get get me thinking about it. The first problem is determining if bountysource reliably pays out claims. There is little transparency, so maybe they only pay out on 50% of bounty claims that are completed...
Yeah it's a decent amount now
Up near 2 weeks wages, for a moderately experienced compiler programmer! Probably not including "burden"...
I guess that's the point of these sites, a kind o wage auction, so that Microchip doesn't have to pay the real cost of doing this. But I understand there will be no takers until the reward is way higher. I'm not taking it, that's for sure.
But isn't there a risk that someone that is not qualified accepts this and does a poor job that just seems to work? Who will do the testing?
... so that Microchip doesn't have to pay the real cost of doing this.
GitHub - embecosm/avr-gcc: A fork of the GCC mainline for work on the AVR tool chain
due to https://www.avrfreaks.net/forum/ok-use-mmcuattiny84-instead-84a#comment-1151476
What guarantee do the bounty players have that a "good job" is done? Code costs money, high quality, reliable, maintainable code costs astronomical amounts of money. Or maybe its Hobson's Coice? They just accept the only offer that turns up.
I hope someone takes the bounty
What guarantee do the bounty players have that a "good job" is done? Code costs money, high quality, reliable, maintainable code costs astronomical amounts of money. Or maybe its Hobson's Coice? They just accept the only offer that turns up.
As I read it, the backers who funded the bounty collectively decide whether or not a particular contributor has done an adequate job.
Personally, at a minimum I would hope that they would observe activity on the GCC bugzilla case tracking this issue, and on GCC's development mailing list, to confirm that the proposed solution was accepted through that project's normal peer review system for official acceptance into the upstream project's git repository.
On the gcc mailing list, I see signs of at least two people actively expressing interest in pursuing this and seeking out advice on next steps.
On the gcc mailing list, I see signs of at least two people actively expressing interest in pursuing this and seeking out advice on next steps.
I'm following that, and glad to see it being worked by motivated people. Also, I'm guessing the gcc maintainers are going to be sanity checking the design.
The challenge I see is that there are 100's - 1000's of forms (e.g., define_insn) in avr.md and other .md files to update.
'Tis my understanding that the issue is trickier on AVRs and other 8-bitters than
for most other gcc targets because a certain amount of int is 32 bits is baked in.
IIRC that is why -lm was (is?) needed to make floating point work correctly.
The generic software floating point code assumed 32-bit ints.
