avr-gcc and avr-g++ are deprecated now.

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

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.

 

https://gcc.gnu.org/ml/gcc-patch...

avrfreaks does not support Opera. Profile inactive.

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

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).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
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.

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

avrcandies wrote:
Is GCC support slowly going away (or becoming lower priority) for AVR's?
Not disappearing though the effort to reach FSF AVR GCC v11 may be significant with a price and cost.

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

 

"Dare to be naïve." - Buckminster Fuller

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

SprinterSB wrote:

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.

 

https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

Forgive me for asking a stupid question, but does this mean there will be no more AVR support after GCC v9.x?

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

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

It doesn't affect V9. The announcement says deprecation at V10 and removal at V11

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

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.

avrfreaks does not support Opera. Profile inactive.

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

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.)

 

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

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.

Last Edited: Sun. Nov 17, 2019 - 02:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
chasing various OS changes

 

It is also about chasing the C/C++ standards, and what if some other language is added.

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

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

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

MattRW wrote:
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.

Note that the change might break some existing code:

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.

Iluvatar is the better part of Valar.

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

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.

 

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

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.

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

clawson wrote:
the as yet unannounced ATWhizzMegaSuper12345

 

Nicknamed the AVR O-Mega.

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

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.

avrfreaks does not support Opera. Profile inactive.

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

avrfreaks does not support Opera. Profile inactive.

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

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

https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

... 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]

 

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

The bounty is up to $315.

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

The bounty is up to $535.

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

Th 68k changes are pretty massive :-(

 

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

Bounty is at $565, increasing by $1per day.

With that speed, it will surpass the 68k bounty in about 13 years...

avrfreaks does not support Opera. Profile inactive.

Last Edited: Sun. Jan 12, 2020 - 12:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bounty at $655 today.

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

The bounty has increased to $1110.

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

Does anyone know whether someone converted MSP430?  That might be a closer example than the 68k.

 

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

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Feb 21, 2020 - 09:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.)

 

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

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.

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

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")])

 

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

bounty is time-limited :

AVR CC0 transition

 

The top bounty is from the CEO of SparkFun Electronics

15 Years of SparkFun - News - SparkFun Electronics

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

bounty is time-limited :

AVR CC0 transition

 

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

support@bountysource.com

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

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

Last Edited: Fri. Jul 24, 2020 - 07:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah it's a decent amount now, but still, I'm sure not many people actually know how to do it.

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

El Tangas wrote:

Yeah it's a decent amount now, but still, I'm sure not many people actually know how to do it.

Might be worth directly approaching the dev(s) who ported the m68k.  Very unlike AVR to be sure, but the overlap cannot be insignificant.

"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]

 

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

El Tangas wrote:

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

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Yeah it's a decent amount now

Up near 2 weeks wages, for a moderately experienced compiler programmer!  Probably not including "burden"...

 

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

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?

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

El Tangas wrote:
... so that Microchip doesn't have to pay the real cost of doing this.
to a first party (a part of Microchip) or a third party (Embecosm)

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

 

"Dare to be naïve." - Buckminster Fuller

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

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.

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

I hope someone takes the bounty

https://www.eevblog.com/forum/mi...

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

clawson wrote:

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.

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

lfmorrison wrote:

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.

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

'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.

Iluvatar is the better part of Valar.

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

"Dare to be naïve." - Buckminster Fuller

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

So it seems someone was working on this and there is a proposed gcc version:  https://github.com/gcc-mirror/gcc/tree/2ab4c1ced160dae1a5ab9562da700b42e4ff740d

 

It needs testing, but honestly I never compiled gcc or avr-gcc :(

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

El Tangas wrote:
So it seems someone was working on this and there is a proposed gcc version:
But there's been no activity on that since August 5th ?

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

clawson wrote:

But there's been no activity on that since August 5th ?

 

Yeah, I guess motivation was in short supply, possibly because lack of feedback?

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

[puts tongue firmly in cheek...]

 

Welcome to the world of open source software!

 

[...takes tongue out of cheek]

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

There was a bit of traffic on the gcc developer's email list around August timeframe (subject "Clobber REG_CC only for some constraint alternatives?").

Nothing after that.  Someone could be head-down working it still.  If given up, I think there'd be an announcement on the bounty.