Add compiler support for AVR architecture (Arduino) #14393

ysbaddaden · 2024-03-25T09:24:27Z

Experimental support for the AVR (Atmel) CPU architectures as found on popular Arduino boards (e.g. Uno).

Supports the avr-unknown-unknown target triple;
Enables the AVR target in LLVM;
Implements the ABI as per GCC AVR (barely tested), with support for both regular and "reduced tiny" cores (less registers);
~~Starts hacking support for 16-bit size_t~~ extracted as Add Program#size_t and Target#size_bit_width #14442;
Requires CPU model to be specified with --mcpu (impacts the ABI, codegen & linker);
Exports the specified CPU model as a compiler flag;
Links the executable program (courtesy of @RX14);
No support for stdlib (must compile with --prelude=empty), for obvious reasons. Alternative stdlib shall happen in external shards.

Initial cross compilations seem to generate a proper file, identical or close to clang and less optimized for size than AVR GCC.

Follow ups:

Add support for -Os (optsize) and -Oz (minsize) with LLVMPassBuilderOptionsSetInlinerThreshold. The thresholds in LLVM are 50 and 5 respectively (I guess clang uses these) while Rust uses 75 and 25. We could also disable some specific optimizations (e.g. loop unrolling). That would help reduce the program size which can be very restricted on AVR (e.g. 32KB). See Add compiler flags -Os and -Oz to optimize binary size #14463.
The compiler hardcodes pointer sizes to 64-bit (Pointer#address, #object_id and pointer manipulation). It would be interesting to have per-target support for size_t and uintptr_t actual sizes, instead of casting and assuming LLVM will optimize.

Basic instructions:

Install the GCC AVR toolchain and avr-libc. On Debian/Ubuntu:

$ apt install gcc-avr avr-libc

Cross compile a crystal binary, specifying the actual CPU (e.g. Arduino Uno uses an atmega328p) and the empty prelude, link it as a .elf file and generate a .hex file:

$ CC=avr-gcc crystal build \
  --target=avr-unknown-unknown --mcpu=atmega328p \
  --prelude=empty --no-debug --single-module -O2 blink.cr
$ avr-objcopy -O ihex blink.elf blink.hex

When #14463 is merged we may use -Os and -Oz to further reduce the executable file size. The --gc-sections linker option is mostly useful when linking external libraries.

Now you should be able to upload the hex file to your AVR board, using avrdude for example.

src/compiler/crystal/codegen/llvm_builder_helper.cr

src/llvm/abi/avr.cr

ysbaddaden · 2024-03-25T10:22:25Z

I broke the compiler with the llvm.memset.* change:

Module validation failed: Call parameter type does not match function signature!
i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64)
 i64  call void @llvm.memset.p0.i64(ptr align 4 %0, i8 0, i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64), i1 false), !dbg !45
Call parameter type does not match function signature!
i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64)
 i64  call void @llvm.memset.p0.i64(ptr align 4 %0, i8 0, i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64), i1 false), !dbg !68
Call parameter type does not match function signature!
  %4 = sext i32 %3 to i64, !dbg !152
 i64  call void @llvm.memset.p0.i64(ptr %1, i8 %value, i64 %4, i1 false), !dbg !153
Call parameter type does not match function signature!
  %10 = mul i64 ptrtoint (ptr getelementptr (i8, ptr null, i32 1) to i64), %9, !dbg !158
 i64  call void @llvm.memset.p0.i64(ptr align 4 %11, i8 0, i64 %10, i1 false), !dbg !158
Call parameter type does not match function signature!
i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64)
 i64  call void @llvm.memset.p0.i64(ptr align 4 %0, i8 0, i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64), i1 false), !dbg !164
Call parameter type does not match function signature!
i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64)
 i64  call void @llvm.memset.p0.i64(ptr align 4 %0, i8 0, i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64), i1 false), !dbg !256
Call parameter type does not match function signature!
i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64)
 i64  call void @llvm.memset.p0.i64(ptr align 4 %0, i8 0, i64 ptrtoint (ptr getelementptr (%"Slice(UInt8)", ptr null, i32 1) to i64), i1 false), !dbg !269

That may be what broke CI :p

straight-shoota · 2024-04-02T10:27:05Z

We should try to pull out changes that are not directly affecting AVR into separate PRs. That's mostly the refactor around size_t I suppose.

ysbaddaden · 2024-04-04T11:50:06Z

The interpreter specs broke on CI with a linker error:

cannot load /__w/crystal/crystal/src/llvm/ext/llvm_ext.o (/__w/crystal/crystal/src/llvm/ext/llvm_ext.o: cannot open shared object file: No such file or directory)

I'm not sure what's happening?

HertzDevil · 2024-04-04T11:52:20Z

You need:

require "spec"

{% if flag?(:interpreted) && !flag?(:win32) %}
  # TODO: figure out how to link against libstdc++ in interpreted code (#14398)
  pending LLVM::ABI::AVR
  {% skip_file %}
{% end %}

require "llvm"

# ...

ysbaddaden · 2024-04-04T11:58:29Z

Thanks @HertzDevil !

ysbaddaden · 2024-04-06T08:59:02Z

I extracted the size_t patches into its own pull request, and rebased this branch off that new pull request, to clean it up and keep it focused on the AVR target.

Support for -Os and -Oz will come in their own PR.

src/llvm/lib_llvm/target.cr

HertzDevil · 2024-04-06T14:07:50Z

Does flag?(:bits8) or flag?(:bits16) hold for AVR?

ysbaddaden · 2024-04-06T16:37:00Z

@HertzDevil I guess it depends on what we want bitsN to mean: are the bits the register size or the usual pointer bit width. I'd say the later?

straight-shoota · 2024-04-06T17:57:34Z

It's implemented via Target#pointer_bit_width, so I'd assume that to be the intention. However, we haven't really had distinctive values yet, so it could just be underspecified.

Anyway, the meaning of bitN flags feels like a separate discussion. We might even want to enhance/replace them with more precise flags that allow a distinction between size and address types.

ysbaddaden · 2024-04-08T07:55:43Z

I'm running some tests to pass structs (seems to be OK) as well as pointers to structs, and I feel like passing pointers isn't working or it's accessing Pointer(T)#value or both. The generated assembly is much more complex than it should be (like it's copying the structs).

There might be something wrong in the ABI.

ysbaddaden · 2024-04-08T10:16:04Z

I don't see an issue in the LLVM IR codegen related to pointers. However the memset call when initializing a struct is wrong: it should call the i16 variant but it's calling the i64 one 🤔

call addrspace(1) void @llvm.memset.p0.i64(ptr noundef nonnull align 1 dereferenceable(16) %.fca.3.insert.fca.2.gep, i8 0, i64 16, i1 false)

The %.fca.X.insert.fca.Y.gep names are weird (clang uses regular %x) but maybe that's normal.

ysbaddaden · 2024-04-08T10:49:35Z

Weird, the c_memset_fun in codegen is using the proper @llvm.memset.p0.i16 name but the LLVM IR contains the i64 one. We might be using Intrinsics.memset somewhere but since :bits64 is false it should default to the i32 version 😕

ysbaddaden · 2024-04-08T11:21:20Z

The non optimized LLVM IR (-O0) properly declares and uses @llvm.memset.p0.i16, while the optimization pass eventually removes it and adds a call to @llvm.memset.p0.i64 🤷

The generated assembly is close to the one generated by clang (again: much less optimized than avr gcc).

I guess it was all a non issue.

ysbaddaden · 2024-04-08T11:43:15Z

I changed Codegen#set_alignment to no longer hardcode the alignment to either 8 or 4, in order to return 1 for the AVR target.

I'll extract the change to its own PR because I'm wondering if we shouldn't delegate to the ABI to get the proper alignment. For example its always 1 for AVR while we still get pointless N bytes alignments for chars, ints and floats... which may waste some space (the ATmega328 only has 2KB of SRAM).

HertzDevil · 2024-04-08T13:42:59Z

I think you could try querying the "preferrred alignment" instead of the "ABI alignment" since it seems Clang sets it up that way. On the other hand that would increase double's alignment from 4 to 8 for 32-bit x86

ysbaddaden · 2024-04-08T15:24:59Z

@HertzDevil I'll look into the "preferred alignment", and yes, the data layout for AVR is to align everything to 8-bit / 1-byte, same as AVR GCC. The i386 change means that the change indeed warrants its own PR.

Apparently clang overrides the data layout to have 4 byte alignment for double:
https://github.com/llvm/llvm-project/blob/2bc637b1ce935550b6e09618c76474253943a7cc/clang/lib/Basic/Targets/X86.h#L442-L453 (I'm not sure what's the layout we use).

ysbaddaden · 2024-04-08T21:19:22Z

I reverted the alignment as it was only used for atomic load & store instructions that don't exist on AVR. Let's tackle that later in its own PR.

RX14 · 2024-04-20T12:11:40Z

I tested this myself, and wrote a little code on an attiny202, which has only 2kb of flash and 128 bytes of ram! Here's a video of blinking lights.

Add support for the `avr-unknown-unknown` target to the compiler, which enables the LLVM AVR target when available (should be compiled in by default). Implement the ABI, following the AVR GCC call convention, hence extern C libraries must be compiled with AVR GCC (clang is buggy when passing of returning some structs). The ABI is experimental, and only basic calls have been verified against the same calls made by AVR GCC so far. Both regular and "reduced tiny" cores (with less registers) are supported.

This allows to know actual support for some features, for example which pins are available.

Don't hardcode the alignment to 4 or 8 when the actual value depends on the actual target (e.g. it's always 1 for AVR targets).

This reverts commit f1b5feb.

- Automatically link the executable program; - Set file extension to ".elf" instead of none; - Require CPU model (--mcpu) that impacts the ABI, codegen & linker

ysbaddaden · 2024-04-21T14:37:41Z

Rebased from master (without any squash) to remove the initial commit that was an older version of #14442 that got merged, and now created a conflict.

spec/std/llvm/avr_spec.cr

src/compiler/crystal/semantic/flags.cr

src/llvm/abi/avr.cr

Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl>

crysbot · 2024-05-14T14:26:03Z

This pull request has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/real-stuff-written-in-crystal/6840/12

crysbot · 2024-05-14T14:27:03Z

This pull request has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/real-stuff-written-in-crystal/6840/13

robacarp · 2024-07-12T04:36:13Z

@ysbaddaden wow! I have been hoping for this for years! 🚀

crysbot · 2024-09-03T14:26:13Z

This pull request has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/crystal-lang-for-microcontrollers/7165/2

ysbaddaden commented Mar 25, 2024

View reviewed changes

src/compiler/crystal/codegen/llvm_builder_helper.cr Outdated Show resolved Hide resolved

ysbaddaden commented Mar 25, 2024

View reviewed changes

src/llvm/abi/avr.cr Outdated Show resolved Hide resolved

HertzDevil added the kind:feature label Mar 26, 2024

HertzDevil mentioned this pull request Apr 2, 2024

[RFC] Simplify integers and floats #8111

Open

straight-shoota assigned ysbaddaden Apr 2, 2024

ysbaddaden force-pushed the feature/avr-architecture branch from eaeba2f to 9475fa3 Compare April 4, 2024 09:41

ysbaddaden force-pushed the feature/avr-architecture branch from 23427b7 to d2cfa7b Compare April 6, 2024 08:48

ysbaddaden mentioned this pull request Apr 6, 2024

Add Program#size_t and Target#size_bit_width #14442

Merged

ysbaddaden marked this pull request as ready for review April 6, 2024 08:59

ysbaddaden commented Apr 6, 2024

View reviewed changes

src/llvm/lib_llvm/target.cr Show resolved Hide resolved

ysbaddaden mentioned this pull request Apr 9, 2024

Add compiler flags -Os and -Oz to optimize binary size #14463

Merged

ysbaddaden added 6 commits April 21, 2024 16:34

AVR: declare CPU as compiler flag

249d1a8

This allows to know actual support for some features, for example which pins are available.

Fix: LLVM::TargetData#to_data_layout must use LLVM.string_and_dispose

8d1b6d3

Fix: memcpy/memmov/memset intrinsics for AVR

f5720d7

Add Program#alignment_byte_width

2ed514a

Don't hardcode the alignment to 4 or 8 when the actual value depends on the actual target (e.g. it's always 1 for AVR targets).

Revert "Add Program#alignment_byte_width"

295bd57

This reverts commit f1b5feb.

AVR: improve build integration

56f453b

- Automatically link the executable program; - Set file extension to ".elf" instead of none; - Require CPU model (--mcpu) that impacts the ABI, codegen & linker

ysbaddaden force-pushed the feature/avr-architecture branch from df638cb to 56f453b Compare April 21, 2024 14:37

straight-shoota reviewed Apr 22, 2024

View reviewed changes

spec/std/llvm/avr_spec.cr Show resolved Hide resolved

src/compiler/crystal/semantic/flags.cr Show resolved Hide resolved

src/llvm/abi/avr.cr Outdated Show resolved Hide resolved

Fix: prefer StaticArray(String) over Tuple(String, String, ...)

1a69b7b

ysbaddaden mentioned this pull request Apr 22, 2024

Expose CPU model (and features?) as compile time flags #14524

Open

straight-shoota approved these changes Apr 29, 2024

View reviewed changes

straight-shoota added this to the 1.13.0 milestone Apr 29, 2024

Sija reviewed Apr 29, 2024

View reviewed changes

src/llvm/abi/avr.cr Outdated Show resolved Hide resolved

mcpu.in?(AVRTINY)

9a8f8fb

Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl>

straight-shoota approved these changes Apr 30, 2024

View reviewed changes

straight-shoota changed the title ~~Feature: AVR architecture (Arduino)~~ Add compiler support for AVR architecture (Arduino) May 2, 2024

straight-shoota merged commit 7ecb968 into crystal-lang:master May 2, 2024
60 checks passed

ysbaddaden deleted the feature/avr-architecture branch May 2, 2024 18:57

straight-shoota mentioned this pull request May 28, 2024

Add flag for avr architecture crystal-lang/crystal-book#763

Merged

straight-shoota added the topic:compiler:codegen label Jun 14, 2024

BrewTestBot mentioned this pull request Jul 10, 2024

crystal 1.13.0 Homebrew/homebrew-core#176873

Merged

1 task

straight-shoota mentioned this pull request Aug 14, 2024

Add AVR target to *Platform Support* crystal-lang/crystal-book#778

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add compiler support for AVR architecture (Arduino) #14393

Add compiler support for AVR architecture (Arduino) #14393

ysbaddaden commented Mar 25, 2024 •

edited

Loading

ysbaddaden commented Mar 25, 2024

straight-shoota commented Apr 2, 2024

ysbaddaden commented Apr 4, 2024 •

edited

Loading

HertzDevil commented Apr 4, 2024

ysbaddaden commented Apr 4, 2024

ysbaddaden commented Apr 6, 2024

HertzDevil commented Apr 6, 2024

ysbaddaden commented Apr 6, 2024

straight-shoota commented Apr 6, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024 •

edited

Loading

ysbaddaden commented Apr 8, 2024

HertzDevil commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024 •

edited

Loading

ysbaddaden commented Apr 8, 2024

RX14 commented Apr 20, 2024

ysbaddaden commented Apr 21, 2024

crysbot commented May 14, 2024

crysbot commented May 14, 2024

robacarp commented Jul 12, 2024

crysbot commented Sep 3, 2024

Add compiler support for AVR architecture (Arduino) #14393

Add compiler support for AVR architecture (Arduino) #14393

Conversation

ysbaddaden commented Mar 25, 2024 • edited Loading

ysbaddaden commented Mar 25, 2024

straight-shoota commented Apr 2, 2024

ysbaddaden commented Apr 4, 2024 • edited Loading

HertzDevil commented Apr 4, 2024

ysbaddaden commented Apr 4, 2024

ysbaddaden commented Apr 6, 2024

HertzDevil commented Apr 6, 2024

ysbaddaden commented Apr 6, 2024

straight-shoota commented Apr 6, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024 • edited Loading

ysbaddaden commented Apr 8, 2024

HertzDevil commented Apr 8, 2024

ysbaddaden commented Apr 8, 2024 • edited Loading

ysbaddaden commented Apr 8, 2024

RX14 commented Apr 20, 2024

ysbaddaden commented Apr 21, 2024

crysbot commented May 14, 2024

crysbot commented May 14, 2024

robacarp commented Jul 12, 2024

crysbot commented Sep 3, 2024

ysbaddaden commented Mar 25, 2024 •

edited

Loading

ysbaddaden commented Apr 4, 2024 •

edited

Loading

ysbaddaden commented Apr 8, 2024 •

edited

Loading

ysbaddaden commented Apr 8, 2024 •

edited

Loading