[AVR] Large const lookup table is placed in data section

[imihajlow]

When compiling for AVR, large const lookup table is placed in data section, wasting precious RAM.

Code in question:

const CURRENT_CALIBRATION_TABLE: [u16; 800] = [ /* ... */ ];

pub const fn get_current_by_adc(adc: u16) -> Fixed {
    let i = if (adc as usize) < CURRENT_CALIBRATION_TABLE.len() {
        adc as usize
    } else {
        CURRENT_CALIBRATION_TABLE.len() - 1
    };
    Fixed::from_bits(CURRENT_CALIBRATION_TABLE[i] as u32)
}

Target spec:

{
  "arch": "avr",
  "atomic-cas": false,
  "cpu": "atmega328p",
  "crt-objects-fallback": "false",
  "data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8",
  "eh-frame-header": false,
  "exe-suffix": ".elf",
  "late-link-args": {
    "gnu-cc": [
      "-lgcc"
    ],
    "gnu-lld-cc": [
      "-lgcc"
    ]
  },
  "linker": "avr-gcc",
  "linker-flavor": "gnu-cc",
  "llvm-target": "avr-unknown-unknown",
  "max-atomic-width": 8,
  "metadata": {
    "description": null,
    "host_tools": null,
    "std": null,
    "tier": null
  },
  "no-default-libraries": false,
  "pre-link-args": {
    "gnu-cc": [
      "-mmcu=atmega328p",
      "-Wl,--as-needed,--print-memory-usage"
    ],
    "gnu-lld-cc": [
      "-mmcu=atmega328p",
      "-Wl,--as-needed,--print-memory-usage"
    ]
  },
  "relocation-model": "static",
  "target-c-int-width": "16",
  "target-pointer-width": "16"
}

I expected to see this happen: Table is placed into Flash ROM, flash read instructions are used to access data.

Instead, this happened: Table is placed into RAM.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (426d17342 2024-12-21)
binary: rustc
commit-hash: 426d1734238e3c5f52e935ba4f617f3a9f43b59d
commit-date: 2024-12-21
host: aarch64-apple-darwin
release: 1.85.0-nightly
LLVM version: 19.1.6

[imihajlow]

Same happens if I use a huge match block instead of an array.

[workingjubilee]

@imihajlow does clang support compiling this table into ROM?

[imihajlow]

@workingjubilee it looks like clang doesn't have __attribute__((__progmem__)) support.

[Patryk27]

There's https://docs.rs/avr-progmem/latest/avr_progmem/, I think there's no point in implementing native support in compiler for that (mostly because it'd be awkward/difficult to force the compiler to guess what should be put inside RAM and what inside ROM).

[imihajlow]

I would suggest to have at least a warning when a large const table (or, even worse, a generated jump table for a match block) is allocated in RAM. Coming from other platforms it may be not obvious at all that having large constant look-up tables can cause a stack overflow (that's what I had when I had my table). The lack of memory protection on AVR makes the issue even worse.

[workingjubilee]

The semantics of a const are defined here, and it is described that they are copied everywhere they are used: https://doc.rust-lang.org/reference/items/constant-items.html#r-items.const.behavior

If you want an item that is definitely only in one place, you need a static. Of course, the opposite is true: two statics cannot be deduplicated.

In addition, an array is Copy, and so you can easily wind up handling multiple copies of it if you are not careful.

If you wish to force moves and avoid additional copies, then you must define a type that does not implement Copy.

[imihajlow]

@workingjubilee what you write here is irrelevant to my problem. The reference does not say how exactly the constants are inlined and in what kind of memory they are allocated, if at all. What I'm saying is that the compiler could have stored constant tables (defined explicitly by the user or auto-generated for match blocks) in the code ROM.

Just to be clear: AVR is Harvard architecture, it has two separate address spaces for code and data. Data RAM is small, code ROM is big. To access the code ROM you need special instructions, since the address space is independent. Tables are unnecessarily placed in the small data RAM.

Example match block that wastes RAM:

pub const fn get_current_by_adc(adc: u16) -> u16 {
    match adc {
       0 => 1000,
       1 => 1021,
       ...
       800 => 15133,
       _ => 15135
   }
}