I am the author of a library that requires knowledge and awareness of integers that are strictly not wider than the general purpose register on the processor; the fact that `usize` is "the largest GPR" on every target Rust knows about is great but I'd still appreciate a distinction between "this fits in exactly one GPR" vs "this fits in the address bus"
_especially_ since the library in question creates pointers that are wider than `usize`
The definition clearly says that `usize` is pointer-sized, and makes no reference to register size, so it seems there's already a pretty clear distinction?
If you are specifically looking for a register sized tyoe then you should define it on a per-architecture basis via `cfg()` options.
One can also argue data width is the size of cache lines, which nowadays often are larger than registers (and might even be different in the various caches, but I don’t know whether such architectures exist)
Beyond this, I speak as one who hasn’t done any embedded work or touched a platform where what this article calls “data width” and “address width” differ.
I suspect that the key here for Rust is that it simply doesn’t have a type for what this article calls “data width”, because it wasn’t found to be useful. I’m not certain why you’d actually need such a type; I’m guessing that the only place it matters is the size of registers, which surface-level Rust doesn’t need to worry about, though I’m not sure if asm! has anything to do with it. I can imagine that things like GPIO pins which might need data width? will be done in a library for a specific board, and can thus define the type themselves.
I also have a vague feeling that there’s also a third concept here, not just the two: that what I’ve called “data width” in the previous paragraph is actually “word size”, which could potentially be smaller again. Something about an 8-bit architecture with 16-bit address space and 32-bit pointers. Can’t remember if register sizes are consistent, either.
I’m writing fairly incoherently and inaccurately here because I really don’t know what I’m talking about. :-)