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

Go To Last Post
18 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: 1

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]