LLVM 8

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

LLVM 8 was released 20-Mar'19.

Download LLVM releases

 

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

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

via The LLVM Compiler Infrastructure Project

It's still experimental for AVR though may be a go for LLVM 9 (maybe northern Fall'19)

AVR appear to be up to XMEGA and reduced core (no unified memory AVR) with 16 bugs current.

Clang has AVR ISR (interrupt, signal)

Found one instance of Clang build (Visual Studio 2017 Community, or, POSIX)

 

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

https://github.com/llvm/llvm-project/tree/master/llvm/lib/Target/AVR#avr-backend

http://clang.llvm.org/docs/AttributeReference.html#interrupt-avr

http://clang.llvm.org/docs/AttributeReference.html#signal

https://github.com/ziglang/zig/wiki/How-to-build-LLVM,-libclang,-and-liblld-from-source#llvm

 

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

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

Has anyone tried LLVM for AVR?

 

I've had decent results on ARM but of course it gets a lot more love than AVR...

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

mojo-chan wrote:
Has anyone tried LLVM for AVR?
not yet for me

Dylan is apparently its primary maintainer :

♟ dylanmckay

 

AVR was presented at

LLVM Project Blog: EuroLLVM'19 developers' meeting program

...

...

 

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

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

Quick comment, the github link was broken because llvm nowadays uses main instead of master as their branch... https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/AVR#avr-backend

 

Most work is done by Ayke (of TinyGo) and Dylan, the AVR backend creator, who has been working on it for about 7 years I think.

 

It is now a mainstream target, not experimental. Bugs still exist but are becoming rare and would usually be only when you use a more unusual front end like Swift.

 

clang should work flawlessly and support for Go and Rust are extremely good. Other more obscure llvm front ends less so.

 

In my experience if you're building for newer chips like the atmega4809 you might get some trouble. I managed to get it working at least for basic blink but it was a challenge!

 

 

footnote: also the instructions for building from source look a little aged too, llvm projects live in a 'monorepo' meaning you check out github.com/llvm/llvm-project, it has multiple directories for related projects: llvm, clang, compiler-rt, lld, lldb and some more obscure things, you no longer need to check out separate source for lld, llvm and clang

Carl Peto
Founder - Swift for Arduino

Last Edited: Mon. May 3, 2021 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome and thanks!

carlos4242 wrote:
It is now a mainstream target, not experimental.
yes

carlos4242 wrote:
... and would usually be only when you use a more unusual front end like Swift.
More front-ends the better; can be a challenge for intermediate representation.

carlos4242 wrote:
In my experience if you're building for newer chips like the atmega4809 you might get some trouble.
AVRxt isn't yet; on product release, up to tiny102/tiny104 inclusive, not yet tiny817.

 


AVR LLVM released | AVR Freaks

 

GitHub - AdaCore/gnat-llvm: LLVM based GNAT compiler (Ada)

 

https://bugs.llvm.org/buglist.cgi?quicksearch=AVR

 

Instruction Set Summary | AVR® Instruction Set Manual (Table 1)

ATtiny417 / ATtiny814 / ATtiny816 / ATtiny817 | AVR Freaks

 

edit :

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AVR/AVRDevices.td#L132

 

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

Last Edited: Mon. May 3, 2021 - 03:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thanks for the welcome. I've been reading here for years. Felt it was time I made an effort to contribute.

 

Sorry, I didn't see your reply just now, I just edited my original comment a bit.

 

You're definitely right about more front ends being extremely important. Not only does it give you more choices of language, each one tends to stress test different parts of the llvm intermediate representation -> AVR MC/asm "back end", making a better compiler overall.

 

 

I am mostly familiar with atmega328p and atmega32u4 as those are the chips I support in my product*.

 

 

I made an experimental "blink" demo of Swift running on the Arduino Nano Every. When I was putting together support for atmega4809, I downloaded the avr8-gnu toolchain and the Atmel.ATmega_DFP.1.6.364 dfpack from the Microchip website. You have to sign up for an account but it's not too difficult (handy hint, I had trouble signing up then had better luck with Google Chrome).

 

The Arduino Nano Every board seemed to advertise it was being run at 20MHz but in reality the fuses were usually set for 16MHz, which threw off my timing at first.

 

When building with llvm front ends, atmega4809 is not a recognised target but I was able to build sensible looking code using atxmega3 (the AVR-Rust guys are using the same trick). Then used the gcc from Atmel/Microchip as the linker together with their libc and c runtime from the DFP pack.

 

Another tip... I had to copy the appropriate specs file into the actual gcc directory hierarchy to make gcc recognise the atmega4809. I struggle a bit with gcc sometimes!

 

 

Carl

 

*I'm the Swift for Arduino guy. Our product is solid for Swift compiling to the Arduino Uno and classic Nano. I'm now looking at branching out to newer AVR based boards, some of the new chips look really cool!

 

Ayke van Laethem is the TinyGo guy and he's very hard working and professional. Dylan McKay is more on the Rust side and is the founder and maintainer of the AVR backend, without him literally all my work would never have been possible. He's a lovely guy too!

 

Feel free to contact me to ask questions if you're curious about Swift for Arduino: www.swiftforarduino.com

Carl Peto
Founder - Swift for Arduino