[C] Low-bit integers

Anikom15 · 2009-12-20 01:21:18

Is there a way I can make integers low-bit? I think short is 16-bits, but how can I declare 8-bit and 1-bit ints?

namegame · 2009-12-20 02:34:48

A short int is 16-bits.

A char can be used as an 8-bit integer.

As far as I know, C does not support 1-bit integers and I'm not exactly sure as to why you would need a 1-bit integer as a one bit integer can only be 0 or 1.

Last edited by namegame (2009-12-20 02:38:12)

PirateJonno · 2009-12-20 03:22:40

i think in c++ there is a way to make a 1-bit int, its something like this:

int bit : 1 = 0;

but it still takes up at least 8 bits unless you have more than one (then together they take 2 of the 8 bits allocated, etc). its a pretty obscure feature though, not sure if its in C either.

hidefromkgb · 2009-12-20 03:44:03

When using ASM, you are able to use integers of 64-bit (EAX:EDX pair on x86-32, or directly RAX/RDX/<other_registers> on x86-64 CPU architecture), 32-bit, 16-bit, and 8-bit (only available for these registers: AX -> AH|AL, DX -> DH|DL, CX -> CH|CL, BX -> BH|BL; also, don't forget about SI -> SIH|SIL and DI -> DIH|DIL accessible only on x86-64).
Single bits cannot be accessed directly, however, there is a wide group of commands like BTC/CLD that allow such thing.

Unfortunately, i cannot say anything that precise about another architectures ArchLinux supports, like PowerPC...

Grazz256 · 2009-12-20 03:46:22

To the best of my knowledge the size of an "int" type (short or otherwise) is not guaranteed and could vary from complier to complier, you can declare variables as uint8_t to make an 8 bit integer (unsigned in this case).

As namegame mentioned chars are generally 8bits but I'm not sure weather that is standardized or not.

If your programing for a modern computer there really is no reason to worry about the difference between a 16 bit integer and an 8 bit integer. Unless of course your planning on creating huge numbers of them...

For smaller values you can pack multiple variables into one byte by using bit flags and masking but I don't think you can declare anything smaller then 8bits.

Cheers,
Jon

Trent · 2009-12-20 17:32:12

A char has CHAR_BIT bits in it; CHAR_BIT is defined in limits.h and not guaranteed to be 8.

Integer types are defined in terms of minimum allowable ranges, not number of bits; however, the ranges are chosen such that an int can hold at least 16 bits without loss of information, a long 32, and a short 8 (if memory serves).

In C99, you can indeed use uintN_t and its relatives to specify an integer of size N, but be aware that this is not (necessarily) the actual size of the integer; it is in fact a minimum size, and the compiler is allowed to choose any integer type wide enough to hold an integer of width N. So your uint1_t is probably 8 bits wide, although the Standard does not require defined behavior if you access any of the 7 bits not guaranteed by the given size.

If you have need of a lot of closely related low-range integers, look into bitfields, which are created for this purpose.

A final word of warning. I understand the interest in making programs as small as possible, but remember:

Donald Knuth wrote:

The premature program optimization is the root of all evils

If your program is consuming too much memory, consider using a less memory-hungry algorithm, not aggressively optimizing the readability out of your original one.

dalingrin · 2009-12-20 23:10:47

Unless you are using ASM, the benefit from using smaller integer sizes is negligible. As Trent said, if you are running into memory consumption problems then look at the algorithm instead of the size of an integer.

tavianator · 2009-12-21 20:23:44

Trent wrote:

A char has CHAR_BIT bits in it; CHAR_BIT is defined in limits.h and not guaranteed to be 8.

It is in C99.

man stdint.h wrote:

As a consequence of adding int8_t, the following are true:
* A byte is exactly 8 bits.
* {CHAR_BIT} has the value 8, {SCHAR_MAX} has the value 127, {SCHAR_MIN} has the value -127 or
-128, and {UCHAR_MAX} has the value 255.

Trent wrote:

In C99, you can indeed use uintN_t and its relatives to specify an integer of size N, but be aware that this is not (necessarily) the actual size of the integer; it is in fact a minimum size, and the compiler is allowed to choose any integer type wide enough to hold an integer of width N.

Actually that's not true either. There's uint_leastN_t for that. For uintN_t, the size is guaranteed to be exactly N bits; for example, (uint8_t)255 + 1 is guaranteed to be zero.

Last edited by tavianator (2009-12-21 20:27:18)

Grazz256 · 2009-12-22 00:39:46

tavianator wrote:

Actually that's not true either. There's uint_leastN_t for that. For uintN_t, the size is guaranteed to be exactly N bits; for example, (uint8_t)255 + 1 is guaranteed to be zero.

Thats how I understand it as well. If there are no variables with guaranteed size it would be very difficult to do anything reliable with binary data. (eg reading files, serial comms etc..)

Trent · 2009-12-22 14:13:49

tavianator wrote:

Trent wrote:
A char has CHAR_BIT bits in it; CHAR_BIT is defined in limits.h and not guaranteed to be 8.
It is in C99.

No. CHAR_BIT still has an implementation-defined value greater than or equal to 8. Just because it happens to be 8 for your implementation (and mine, as it happens) does not mean it is 8 everywhere. The manpage you quote is documentation for a specific implementation, not true for the Standard at large.

Trent wrote:
In C99, you can indeed use uintN_t and its relatives to specify an integer of size N, but be aware that this is not (necessarily) the actual size of the integer; it is in fact a minimum size, and the compiler is allowed to choose any integer type wide enough to hold an integer of width N.
Actually that's not true either. There's uint_leastN_t for that. For uintN_t, the size is guaranteed to be exactly N bits; for example, (uint8_t)255 + 1 is guaranteed to be zero.

You're right, and I knew that but misspoke. However, the point I was trying to make was this: you probably don't gain any space by using int4_t rather than int8_t, because the compiler is unlikely to try to fit two 4-bit integers into a single 8-bit space, because (again, for my particular implementation) they are not separately addressable (and any attempt to take the address of such an integer with the & operator must be defined by the Standard). A really agressive optimizing compiler could do it, if it observes that the code never takes the address of an int4_t.

But I feel I'm straying way off the topic... bottom line, you probably don't save space by using intN_t, although they are useful for other reasons.

Grazz256 · 2009-12-22 15:53:42

I may be doing something wrong but I can only find down to int8_t anyway...

Trent · 2009-12-22 16:10:55

The intN_t types are only guaranteed to exist for N = 8, 16, 32, and 64, and that only if the implementation provides integer types of the appropriate widths (int64_t is not required to exist if there is no basic 64-bit integer type).

I don't want to pursue this discussion of the C99 standard on the Arch forums, but I'll post a link to it for the benefit of those who come across this thread in the future: http://www.open-std.org/JTC1/sc22/wg14/ … dards.html

Arch Linux

#1 2009-12-20 01:21:18

[C] Low-bit integers

#2 2009-12-20 02:34:48

Re: [C] Low-bit integers

#3 2009-12-20 03:22:40

Re: [C] Low-bit integers

#4 2009-12-20 03:44:03

Re: [C] Low-bit integers

#5 2009-12-20 03:46:22

Re: [C] Low-bit integers

#6 2009-12-20 17:32:12

Re: [C] Low-bit integers

#7 2009-12-20 23:10:47

Re: [C] Low-bit integers

#8 2009-12-21 20:23:44

Re: [C] Low-bit integers

#9 2009-12-22 00:39:46

Re: [C] Low-bit integers

#10 2009-12-22 14:13:49

Re: [C] Low-bit integers

#11 2009-12-22 15:53:42

Re: [C] Low-bit integers

#12 2009-12-22 16:10:55

Re: [C] Low-bit integers

Board footer