Support AVRTiny devices in AVR inline assembly #146901

taiki-e · 2025-09-22T17:59:44Z

Note: This is still draft and this depends on #146900 which adds necessary target feature. (The first commit is from it.)

Follow-up to #131323.

AVR has devices that reduce the number of registers, similar to RISC-V's RV32E, which have different ABI than default. This PR supports such devices in inline assembly.

Refs: AVR-GCC docs https://gcc.gnu.org/wiki/avr-gcc#Reduced_Tiny

On the Reduced Tiny cores (16 GPRs only) several modifications to the ABI above apply:

Call-saved registers are: R18–R19, R28–R29.
Fixed Registers are R16 (tmp_reg) and R17 (zero_reg).

Registers used to pass arguments to functions and return values from functions are R25...R20 (instead of R25...R8).
Values that occupy more than 4 registers are returned in memory (instead of more than 8 registers).
There is only limited library support both from libgcc and AVR-LibC, for example there is no float support and no printf support.

r? @Amanieu

@rustbot label +O-AVR +A-inline-assembly

tgross35 · 2025-09-22T18:44:48Z

Cc target maintainer @Patryk27

compiler/rustc_target/src/asm/avr.rs

Patryk27 · 2025-09-23T17:02:50Z

tests/ui/asm/avr/bad-reg.rs

+        asm!("", out("r15r14") _);
+        //[avrtiny]~^ ERROR on AVRTiny, r[2-15] are unavailable, r16 (scratch register) and r17 (zero register) are reserved by LLVM
+        asm!("", out("r17r16") _);
+        //[avrtiny]~^ ERROR on AVRTiny, r[2-15] are unavailable, r16 (scratch register) and r17 (zero register) are reserved by LLVM


nit: would be nice to have a different message for register pairs, otherwise it takes a moment to parse what the compiler is trying to say

Amanieu · 2025-09-26T17:59:12Z

r=me once the target features land

bors · 2025-11-05T08:32:17Z

☔ The latest upstream changes (presumably #147645) made this pull request unmergeable. Please resolve the merge conflicts.

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

Rollup merge of #146900 - taiki-e:avr-target-feature, r=workingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: #146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also #146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See #146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

taiki-e · 2026-02-07T17:30:02Z

The target feature PR has been merged and I rebased this PR.

rustbot assigned Amanieu Sep 22, 2025

taiki-e changed the title ~~Support AVRTiny devices AVR inline assembly~~ Support AVRTiny devices in AVR inline assembly Sep 22, 2025

This was referenced Sep 22, 2025

Tracking Issue for asm_experimental_arch #93335

Open

Add avr_target_feature #146900

Merged

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avrtiny branch from 2a9be64 to e2abd1e Compare September 22, 2025 18:20

Patryk27 reviewed Sep 23, 2025

View reviewed changes

compiler/rustc_target/src/asm/avr.rs Show resolved Hide resolved

Patryk27 reviewed Sep 23, 2025

View reviewed changes

taiki-e force-pushed the avrtiny branch from e2abd1e to 32e50a2 Compare February 7, 2026 12:56

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avrtiny branch from 32e50a2 to d768130 Compare February 7, 2026 13:58

This comment has been minimized.

Sign in to view

Support AVRTiny devices in AVR inline assembly

b2dd13a

taiki-e force-pushed the avrtiny branch from d768130 to b2dd13a Compare February 7, 2026 15:32

taiki-e marked this pull request as ready for review February 7, 2026 17:29

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 7, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support AVRTiny devices in AVR inline assembly #146901

Support AVRTiny devices in AVR inline assembly #146901

Uh oh!

taiki-e commented Sep 22, 2025 •

edited

Loading

Uh oh!

This comment has been minimized.

tgross35 commented Sep 22, 2025

Uh oh!

Uh oh!

Patryk27 Sep 23, 2025 •

edited

Loading

Uh oh!

Amanieu commented Sep 26, 2025

Uh oh!

bors commented Nov 5, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

taiki-e commented Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Support AVRTiny devices in AVR inline assembly #146901

Are you sure you want to change the base?

Support AVRTiny devices in AVR inline assembly #146901

Uh oh!

Conversation

taiki-e commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

tgross35 commented Sep 22, 2025

Uh oh!

Uh oh!

Patryk27 Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Amanieu commented Sep 26, 2025

Uh oh!

bors commented Nov 5, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

taiki-e commented Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

taiki-e commented Sep 22, 2025 •

edited

Loading

Patryk27 Sep 23, 2025 •

edited

Loading