Structs and odd integer types

1

I'm writing a program that uses quite a few wierd integer types to hold odd size data.

Below is my current understanding of structs and how much data they take up. There isn't really a u3 or u7 type, just crates that provide structs wrapping the closest primitive but enforcing a lower limit.

struct Shape {
    shape: u16,
    width: u8,
    height: u8,
    weight: u8,
} // theoretically 48 bit

struct Shape {
    /// Takes up 16 bits because it is just a struct wrapping a u16.
    shape: u9,
    width: u2,
    height: u2,
    weight: u3,
} // theoretically still 48 bit

This works, but it kind of sucks though. My understanding is that whilst struct sizes have to be a multiple of a byte, it is theoretically possible to "pack" these fields (that are not multiples of a byte) into two bytes instead of "padding" them into four.

Not a big deal, and I might be misunderstanding this, but it just seems wasteful to me, even on a machine with plenty of ram.

2

This is only true if your struct has an alignment of 1 byte, as the size of a type is a multiple of its alignment.

3

CPU registers can be accessed as byte(U8), word(U16), dword(U32) and U64.

Trying to force "in-between" bit count units would just slow things down and is a waste of effort.

If max value 255 or less use U8, if max value 65,535 or less use U16, etcetera.

(my question) Does Rust STRUCT support bit array.? If so, then you can have your second sample in a U16. Still slows things down a bit by "behind the scenes" code to get the values into a register.

Cheers,

4

It's not possible while also giving out &muts to them, though.

What this needs is a new feature often called "move-only fields" that would block getting references, thus allowing rust to run code when ever it's read or written, and thereby allowing more freedom for layout optimization.

3 Likes
5

There are crates like bitvec:

6

Thanks.

My reply to original poster still okay.

7

This is not necessarily true. Yes, bit-packing and unpacking requires extra instructions, but on today’s computers, many instructions can execute in the time it takes to fetch a single piece of data from main memory (a cache miss). Therefore, in some applications, reducing the size of structs, even by explicit bit-packing and unpacking, can be beneficial by allowing more data to fit in cache at once.

8

This is commonly called “bitfields” after the C feature. There are a few crates if you search with that term.

9

Then tell original poster how to do bit packing!
(though i still think its a waste of effort)

10

There are two other posts pointing to crates commonly used for bit fields -- using those crates is how you do it. The std library doesn't have bit field APIs.

11

Well, as @jdahlstrom said, you can use a library, and that's what I would recommend if you have multiple structs or are not greatly familiar with bit manipulation.

But for a small case, doing it from scratch is “just” writing getters and setters:

struct Shape(u16);

impl Shape {
    fn new(shape: u16, width: u8, height: u8, weight: u8) -> Self {
        assert!(shape <= 0b1_1111_111);
        assert!(width <= 0b11);
        assert!(height <= 0b11);
        assert!(weight <= 0b111);
        
        Self(shape | (u16::from(width) << 9) | (u16::from(height) << 11) | (u16::from(weight) << 13))
    }

    fn shape(&self) -> u16 {
        self.0 & 0b1_1111_1111
    }
    fn width(&self) -> u8 {
        ((self.0 >> 9) & 0b11) as u8
    }
    fn height(&self) -> u8 {
        ((self.0 >> 11) & 0b11) as u8
    }
    fn weight(&self) -> u8 {
        ((self.0 >> 13) & 0b111) as u8
    }
    
    fn set_shape(&mut self, value: u16) {
        let mask = 0b1_1111_1111;
        assert!(value & mask == value, "out of range");
        self.0 = (self.0 & !mask) | value;
    }
    // ...
}

#[test]
fn test() {
    let s = Shape::new(1, 2, 3, 4);
    assert_eq!(s.shape(), 1);
    assert_eq!(s.width(), 2);
    assert_eq!(s.height(), 3);
    assert_eq!(s.weight(), 4);
}
3 Likes
12

pushing glasses up nose well technically, they're not wrong; every alignment is still a multiple of 1 byte

2 Likes
13
14

Sure, but we are talking about a type's size. Take OP's struct, for example. All fields combined take up 5 bytes, but Shape has an alignment of 2. 5 is not a multiple of 2, so the compiler adds padding to increase its size to 6 bytes. This is what I wanted to highlight.

1 Like
15

Bit flags are a bit different. I mean crates like bitfield or bitfield-struct or bilge.

1 Like
16

I was mostly just making a joke, but I believe the structures the OP was referring to getting rounded up to a byte were the u3 etc types, and those will surely always have equal size and alignment

Also be careful not to assume that the size must be a multiple of the alignment in other languages! I had "fun" with that recently...

1 Like