Here's hoping we can wire that up in Rust.
(hannah shared more details on discord (#design room) but this is mostly news for clang/C, it's always been supported in LLVM IR)
I assume that https://github.com/rust-lang/rfcs/pull/2581 will use this feature in LLVM
tried performing division using
_ExtInt(8192), and clang ICE with "error in backend: Unsupported library call operation!" :upside_down:
_ExtInt(128) is the highest type supporting
%, as expected.
While it's always been theoretically supported in IR, it'll probably mean it has fewer rough edge, which is nice.
I often wish we could have
u63 and such -- we have a ton of APIs that take a usize where you're prohibited from setting the high bit
there were some suggestions regarding using const generics for arbitrary-width integers, though I can't remember how nice the APIs were
Yep, there's a ton of low-level data structures that could benefit from it too. Like taking 9 bits out of a virtual address to index a page table.
I'm dealing with many u48 and u40 values lately.
And in one case, a u34 value...
The PNG spec says that image dimensions are supposed to be the equivalent of what Rust would call
NonZeroU31. And a lot of MMIO would benefit from some sort of bitfields struct support combined with arbitrary width integers.
I believe this clang extension is completely unrelated to bitfields.
_ExtInt types are bit-aligned to the next greatest power-of-2 up to 64 bits
So basically these types still use up the same amount of memory as normal integers but have operations on them effectively automatically truncated to a certain bit width.
That would make them helpful for implementing bitfield semantics, though.
@Josh Triplett Hm, I don't see how that's true? You'd (if I understand correctly) not be able to use these for bit fields because
a: u1, b: u1 takes up two bytes still
It might have to be kinda jiggered a bit on the Rust side of things, where you have a setter that takes a
u3 or something and then stores it in a
u16or whatever by upcasting it and then shifting it into place and such.
In Rust yes. I meant that with C-style bitfields, you could write
_ExtInt(5) fieldname: 5; and you'd have a field that not only takes up five bits, but operates as a five-bit number type.
That would need more wiring up to work in Rust, not least of which, having bitfield support. :)
no-ref fieldname: u5 ;)
I sort of like how zig did this, they allow references to bitfields by encoding the offsets in the type