I have a library that I intend to be portable. I want to make sure I'm not inadvertently assuming usize is at least 32 bits somewhere.
Is there a way to force usize to be 16 bit for testing?
I have a library that I intend to be portable. I want to make sure I'm not inadvertently assuming usize is at least 32 bits somewhere.
Is there a way to force usize to be 16 bit for testing?
Probably the oddest thing I could think of, but you could try adding type usize = u16;
at the top of each file. Temporarily or behind a flag only used for testing, of course.
That's an interesting suggestion although it breaks in a few trivial use cases (e.g. you can't index a slice with a u16
).
Rust can be compiled to code that runs on the 8 bit AVR micro-controllers.
I presume usize is 16 bits there. So that would be a good test platform.
You won't be using anything from std though.
The target JSON provided in the article gives you that information:
{
"target-pointer-width": "16",
"data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
}
The specification for data-layout
can be found in the LLVM IR documentation. This target has 16-bit pointers, so yes it can hypothetically work for this use case. Another alternative is using the built-in avr-unknown-gnu-atmega328
or msp430-none-elf
targets, which both have 16-bit pointers.
There are some caveats, though; no standard library port for any of these targets is the biggest hurdle. -Z build-std
does not work on 16-bit architectures because hashbrown
only supports 32-bit and 64-bit. I was able to get cargo-xbuild
to build a MSP430 target, but it's #[no_std]
and may not work with OP's library at all...
They don't specify, but I assume if there is a need to target 16-bit architectures, their library would in fact be #[no_std]
and they would also have an environment capable of running such a build. That's a lot of assumptions. ¯\_(ツ)_/¯
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.