Skip to content

Supported target_pointer_width: 32, 64-bit only? #1468

Closed
@dhardy

Description

@dhardy

All tier 1 and tier 2 platforms supported by Rust are 32- or 64-bit.

#1144 is the only issue I see regarding 16-bit support. Apparently this worked, but has been disabled since (#1269). Attempting to compile now:

$ rustc -V
rustc 1.81.0-nightly (24d2ac0b5 2024-07-15)

$ cargo build -Z build-std=core --target=avr-unknown-gnu-atmega328 --no-default-features
  Downloaded addr2line v0.22.0
  Downloaded gimli v0.29.0
  Downloaded object v0.36.0
  Downloaded 3 crates (636.7 KB) in 0.25s
   Compiling compiler_builtins v0.1.109
   Compiling core v0.0.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
error: ran out of registers during register allocation

   Compiling rustc-std-workspace-core v1.99.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
error: could not compile `core` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

$ cargo build -Z build-std=core --target=msp430-none-elf --no-default-features
   Compiling core v0.0.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.109
   Compiling rustc-std-workspace-core v1.99.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling zerocopy v0.7.35
error[E0080]: evaluation of constant value failed
  --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/macro_util.rs:69:21
   |
69 | const _64K: usize = 1 << 16;
   |                     ^^^^^^^ attempt to shift left by `16_i32`, which would overflow

error[E0080]: evaluation of constant value failed
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:456:69
    |
456 |     const CURRENT_MAX_ALIGN: NonZeroUsize = match NonZeroUsize::new(1 << 28) {
    |                                                                     ^^^^^^^ attempt to shift left by `28_i32`, which would overflow

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:575:47
    |
575 |             debug_assert!(self.align.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:576:48
    |
576 |             debug_assert!(field.align.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:578:52
    |
578 |                 debug_assert!(repr_packed.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0080`.
error: could not compile `zerocopy` (lib) due to 2 previous errors

As far as I can tell, these are the only 16-bit Tier 3 targets, and the first fails to build the core library while zerocopy fails to build the second (@josephlr).

I don't see Rust support for any other pointer width.


Summary: our code can assume that the pointer width is 32 or 64 bits.

We should make this assumption explicit where code depends on this, e.g.:

#[cfg(not(any(target_pointer_width = "32", target_pointer_width = "64")))]
const _: () = assert!(false, "unsupported pointer width");

(I'm working on a related PR.)

If anyone wishes to revive 16-bit support, then first we need a functional test platform (including dependencies). It may make sense to limit support to a small subset of rand. It will be considered at best a second-class platform, and tests will be disabled if they become problematic again.

Metadata

Metadata

Assignees

No one assigned

    Labels

    E-questionParticipation: opinions wanted

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions