AVR LLVM released

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

The LLVM Compiler Infrastructure Project

<home page URL>

(right column, top)

Latest LLVM Release!

13 March 2017: LLVM 4.0.0 is now available for download! LLVM is publicly available under an open source License.

LLVM 4.0.0 Release Notes

Changes to the AVR Target

<URL>

This marks the first release where the AVR backend has been completely merged from a fork into LLVM trunk. The backend is still marked experimental, but is generally quite usable. All downstream development has halted on GitHub, and changes now go directly into LLVM trunk.

...

via

<VIA>

 

Edit : re-try 2

 

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

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

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

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

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

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

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

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

gchapman wrote:
The backend is still marked experimental, but is generally quite usable.

Think I'll give it a while to "mature" then.

 

It only took avr-gcc about 5 years to get pretty good!

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

Good call!

Arrival probably this northern Fall (LLVM 11)

http://llvm.org/docs/ReleaseNotes.html#changes-to-the-avr-target

 

edit :

most recent AVR are the updates to tiny10 (tiny102, tiny104); iow, no PB megaAVR.

https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AVR/AVRDevices.td

 


https://github.com/llvm/llvm-project/tree/master/llvm/lib/Target/AVR#useful-links

 

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

Last Edited: Wed. May 20, 2020 - 07:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

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

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

 

I just tried 11.0.0-rc5.  It appears avr code generation is working, creating .o files in elf format.  However the linker doesn't seem to support avr:

clang --target=avr -mmcu=atmega328 main.c -Os -o main.elf
clang-11: warning: no avr-gcc installation can be found on the system, cannot link standard libraries [-Wavr-rtlib-linking-quirks]
clang-11: warning: standard library not linked and so no interrupt vector table or compiler runtime routines will be linked [-Wavr-rtlib-linking-quirks]

 

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

 

Last Edited: Mon. Oct 5, 2020 - 11:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like the compiler works, but they want the avr-libc and etc that is normally shipped with gcc.  (It doesn't look like "no linker support", it looks like "I don't know where any of the standard stuff that I'm supposed to link IS."

 

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

westfw wrote:

Sounds like the compiler works, but they want the avr-libc and etc that is normally shipped with gcc.  (It doesn't look like "no linker support", it looks like "I don't know where any of the standard stuff that I'm supposed to link IS."

 

 

Since the warning says "no avr-gcc installation", I thought it was trying to use avr-gcc(avr-ld) for linking.  It really should say "no avr-libc installation".

 

I fired up my debian vm again and installed avr-libc (apt install avr-libc), and now can get a binary elf with "clang --target=avr -mmcu=atmega328 -Os main.c -o main.elf".

 

The only target I've found that works is the m328.  Trying various attinies, m8, and even m168 gives the following warning, and generates a 0-byte output file.

clang-11: warning: support for linking stdlibs for microcontroller 'atmega168' is not implemented [-Wavr-rtlib-linking-quirks]

 

Attempting to use LTO gives the following error:

no lto support: clang-11: error: 'avr': unable to pass LLVM bit-code files to linker

 

llvm puts a reference to __do_copy_data and __do_clear_bss in every .o, even when there are no global or static variables declared.  avr-gcc only does this when required.

 

To use avr/io.h, the include path /usr/lib/avr/include needs to be passed to clang.  If you use util/delay.h, __DELAY_BACKWARD_COMPATIBLE__ must be defined because llvm does not implement __builtin_avr_delay_cycles.

 

With -Os, clang's function-level optimization seems on par with avr-gcc 7.3.0 for the few tests I tried.  For example it knows to compile "PORTB |= 1;" to "sbi PORTB, 0".

 

So it sort of works, if your only target is the m328, and you don't want link-time optimization.  I suspect adding target support for the rest of the avr-libc devices isn't overly complicated, but learning llvm internals isn't on my priority list.

 

p.s. I also noticed llvm-objdump doesn't recognize the jmp instruction, and can't calculate target offsets for the rjmp and branch instructions.

b2: ff cf         rjmp    <unknown>

 

b2: ff cf         rjmp    <unknown>
/usr/lib/avr/include
clang --target=avr -mmcu=atmega328 -Os main.c -o main.elf
clang --target=avr -mmcu=atmega328 -Os main.c -o main.elf

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

 

Last Edited: Tue. Oct 6, 2020 - 12:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ralphd wrote:
So it sort of works, if your only target is the m328,
Wonder if it's a coincidence that is the main "Arduino CPU". If I was developing a new compiler I think I might concentrate on the "most used" AVR as my first target too.

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

clawson wrote:

ralphd wrote:

So it sort of works, if your only target is the m328,

 

Wonder if it's a coincidence that is the main "Arduino CPU". If I was developing a new compiler I think I might concentrate on the "most used" AVR as my first target too.

 

That seems to be a reasonable conclusion.

 

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

 

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

mega32U4 or mega328PB though Clang 10 :

Failed experiments with AVR+Clang+cmake : LLVM

 

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

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

[llvm-dev] LLVM 11.0.0 Release

...

One highlight is that the Flang Fortran frontend is now part of the release.

...

 

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

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

gchapman wrote:

is that the Flang Fortran frontend 

Sorry, are you saying we could now program AVRs in FORTRAN ?

 

(I had a lot of fun with FORTRAN when I first started Uni - BASIC for grown ups).

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

clawson wrote:
Sorry, are you saying we could now program AVRs in FORTRAN ?
Not yet

clawson wrote:
(I had a lot of fun with FORTRAN when I first started Uni - BASIC for grown ups).
Kinda likewise though my fun was Z80 assembly which led to 1802 assembly for part of a cooperative education job with FORTRAN on a DEC PDP-11/34.

 


Introducing Flang | Flang 11.0.0 Release Notes — The Flang Compiler

...

Flang is still a work in progress for this release and is included for experimentation and feedback.

...

Flang is not yet able to generate LLVM IR for the source code and thus is unable to compile a running binary.

...

Another WIP is an Ada frontend to LLVM :

GitHub - AdaCore/gnat-llvm: LLVM based GNAT compiler

 

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

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

FORTRAN, unlike C, requires a substantial run-time environment that isn’t quite the same as just a “library.”

that C doesn’t is imho one of the main reasons it was (and remains) so successful...

 

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

westfw wrote:
FORTRAN, unlike C, requires a substantial run-time environment that isn’t quite the same as just a “library.”

that C doesn’t is imho one of the main reasons it was (and remains) so successful...

That surprises me.

Google has not been my friend.

What does FORTRAN need?

I've seen pages descibing how to install a FORTRAN runtime,

but nothing about what it does.

Iluvatar is the better part of Valar.

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

skeeve wrote:

I've seen pages descibing how to install a FORTRAN runtime,

but nothing about what it does.

 

Math, it does math, but Python is the new FORTRAN (e.g., https://numpy.org/ and the like).

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

Well, consider that IO in FORTRAN is part of the language.  Something like:

  

        write (*,*) 'Sum = ', sum, ' and the average = ', r

 

is NOT a function (doesn't LOOK like a function, doesn't ACT like a function) that you can provide separately or omit for code-size reasons (like printf())

And fortran IO is quite "rich", and is a significant part of a lot of fortran code.

 

I suppose it MIGHT be possible to finesse this the way avr-libc finesses stream into files...  "Just provide these getc/put/etc primitives and it'll all be fine."  But there's a lot of "etc" there.

A lot of older languages are like that.  They include IO as a language feature rather than an library feature.  So you need a lot of extra system-dependent code.

I'm not immediately able to recognize any other language features that require much run-time support (math doesn't count.  C needs math primitives too.  Although again... libraries vs language...

 

(I guess Python went through some of this in the 2.x to 3.x transition?  "print" used to be a magic python language item, and then it was a function...)

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

westfw wrote:
Well, consider that IO in FORTRAN is part of the language.  Something like:

  

        write (*,*) 'Sum = ', sum, ' and the average = ', r

 

is NOT a function (doesn't LOOK like a function, doesn't ACT like a function) that you can provide separately or omit for code-size reasons (like printf())

And fortran IO is quite "rich", and is a significant part of a lot of fortran code.

I get the point, though I think that that is not a good example.

I can see this easily being compiled to a call to printf.

That said, fortran formats are a bit more complicated than printf format strings.

They can still be interpreted with function calls.

I recall reading of one case in which that was not done.

An IO statement for an IBM 370 exceeded the compiler's

maximum code size for a single statement.

My recollection is that it had format statements referring to other format statements.

'Tain't clear that runtime interpretation would be all that complicated.

More tedjous than complicated.

The decision tree would be more of a shrub: most of the branching near the root.

Iluvatar is the better part of Valar.