Repository navigation
Supported target_pointer_width: 32, 64-bit only? #1468
Description
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.
Activity
dhardy commentedon Jul 17, 2024
Value-portability: we make some effort to make results like sequence shuffling reproducible across 32- and 64-bit platforms (for lists up to
u32::MAXlong). 16-bit platforms are excluded (and may skip value stability tests).jhpratt commentedon Feb 25, 2025
As a library author (for
derangedspecifically), this in combination with #1487 (ripping outisizeentirely) are major pains. I am deliberately not making any decisions based on what I believe downstream users are doing, merely providing wrappers for range-bound integers. While I could conceivably work aroundisizeandusizeby calling the relevant methods gated by#[cfg], this remains impossible becauserandrefuses to compile on 16 bit platforms — something I want to support.It seems to me that the primary rationale is a combination of the targets being tier 3 and making seeded randomness the same across platforms?
I'm not urging you to reconsider, but I do wish to express my frustration that these changes have brought about. Frankly, I'm seriously considering simply not supporting rand 0.9 because of it; it's not worth the hassle on my end.
dhardy commentedon Feb 25, 2025
Is there some particular 16-bit target you want to support?
As far as I can tell, the only listed Rust target which is not 32- or 64-bit is AVR and this is stale and broken. The AVR-Rust appears to be abandoned.
And honestly, I'm not surprised. 16-bit targets are very memory constrained and Rust binaries are typically not that small, while the low complexity limit due to this memory constraint means that most of the advantages that a complex language like Rust has over C are lost. And 32-bit CPUs are cheap and ubiquitous today.
So is there actually a 16-bit target worth trying to support? (And can we have a CI test which at least builds for that target and isn't prone to breaking frequently?)
Regarding
isize, I've already had a couple of PRs try to re-introduce this functionality. I might reconsider (given a valid actual use-case), but that's a new issue.But, honestly, I'd suggest you simply drop support for
StandardUniformon theRangedIsizetype.jhpratt commentedon Feb 25, 2025
There is no particular platform that I wish to support beyond being able to do so in principle. I'm not an embedded nerd...Raspberry Pis are good enough for me.
Regarding
isizeandusize, the only thing I'd like it to do is its previous behavior, that being a random u16/32/64 as appropriate. Trying to shoehorn in it being used as an index, while notable for portability, seems somewhat odd given that every other primitive type uses the full range of values.dhardy commentedon Feb 25, 2025
I have no problem with supporting an actual target in principle, but from what I can tell there is no maintained 16-bit Rust target.
jhpratt commentedon Feb 26, 2025
That's fair. At the least, not having 16 bit platforms wouldn't stop me from writing the library in the manner I intend; any errors would necessarily arise from
rand.