Ndtyjky

I understand that this is sort of bizarre question, but I have a few thoughts about and it made me interested.

example:
how can I get 31 bit data type or something?)

right now I think that the answer is a flat out NO, you cannot.
maybe I'm wrong?

You can always implement wrapping to whatever width manually, like a++; a&=0x7fffffff; to mask the result to 31 bits and implement an unsigned 31-bit type. Redoing sign-extension to a wider type is more expensive, typically left-shift then arithmetic right shift unless the source width is supported specially by the language and/or hardware. (e.g. ARM has a signed-bitfield-extend instruction that can extract and sign-extend an arbitrary bitfield into a full integer register).

There are CPUs with words and/or bytes that aren't multiples of 8 bits, e.g. PDP-10 has 36-bit words. https://en.wikipedia.org/wiki/36-bit. On that system, the natural size is 36 bits, and 32 bits would be a non-standard type that requires extra instructions.

could I have some kind of data structures that will be store in memory like 31 bit -> 31 bit -> 31 bit and can I made CPU work with them as 31 bit.

No, you can't do that. There are no CPUs I'm aware of with bit-addressable memory. Any load/store has to be aligned to at least byte boundaries. (Byte-addressable memory is nearly universal these days, but some DSPs and some older CPUs like DEC Alpha only have/had word-addressable memory).

C with bitfields will emulate narrower types but with padding; you can't avoid having the compiler-generated asm touch the padding.

e.g.

struct i31 {

    int i:31;   // note *signed* int

    // 1 bit of padding is implicit on targets with 32-bit int

};



struct i31 inc(struct i31 x) {

    x.i++;

    return x;

}



int extend_to_int(struct i31 x) {

    return x.i;

}

compiles for x86-64 to this (on the Godbolt compiler explorer).

I should probably have used gcc -fwrapv to define the behaviour of signed overflow as 2's complement wraparound. I'm not sure what the C rules are for bitfields, whether assignment of a signed result to a signed bitfield still triggers signed overflow undefined-behaviour in ISO C and C++.

# gcc8.2 -O3

inc(i31):

    lea     eax, [rdi+1]

    and     edi, -2147483648   # keep the top bit of the input

    and     eax, 2147483647    # keep the low 31 bits of i++

    or      eax, edi           # merge.

          #   IDK why it can't / doesn't just leave the carry-out in the padding

    ret

extend_to_int(i31):

    lea     eax, [rdi+rdi]     # left shift by 1 (and copy)

    sar     eax                # shift arithmetic right (by 1)

    ret

But ARM is neat and has better bitfield instructions than x86. (Nearly everything has better bitfield instructions than x86).

# ARM gcc7.2 -march=armv8-a -O3

inc(i31):

    add     r3, r0, #1

    bfi     r0, r3, #0, #31    # bitfield insert to preserve the high bit of the struct

    bx      lr

extend_to_int(i31):

    sbfx    r0, r0, #0, #31    # signed bitfield extract

    bx      lr