Why no 1-bit object?

[MonDie]

Okay, two questions.

 

Can a C++ executable output the binary of a value?

 

Why are all C++ objects at least 8 bits? Even bool, a binary true/false variable, usually occupies 8 bits (1 byte).

[Sensei]

Because CPU is storing/reading data to/from memory in bytes/words/long words/long long words.

 

To manipulate single bits, read byte, set/clear bit, and store byte.

 

f.e.

 

unsigned char data;

 

data |= 1<<x; // set bit x=0...7

or

data = ( data | 1<<x );

 

data &= ~( 1<<x ); // clear bit x=0...7

or

data = ( data & ~( 1<<x ) );

[Strange]

And there are bitfields: http://en.cppreference.com/w/cpp/language/bit_field

 

Only really useful for programming hardware, though.

[EdEarl]

You can define and use bit fields, but the masking operations (&& and ||) must be used to access bits. Thus, it is faster to use a byte or larger storage cell and waste the extra bits, unless you have an array of bits, in which case the masking operations can be warranted.

[MonDie]

Perhaps the question is better rephrased to : Why are objects always byte-sized (multiples of 8, where 8 bits = 1 byte)? Couldn't you make more efficient programs if a 3 bit type were available, for example?

Does the obejct (the binary sequence representing variable info, that is) also have to store the name of the variable in addition to its value? But couldn't restrictions be placed on name-sizes, forcing the programmer to rely on re-initialization rather than the creation of independent objects with unique names?

Where do objects with no further importance go to anyway? Would a preference for re-initialization (or re-assignment?) result in smaller object files?

Edited January 21, 2015 by MonDie

[Strange]

Couldn't you make more efficient programs if a 3 bit type were available, for example?

 

There are a few, specialised, architectures that support direct and efficient access to arbitrary bits. The thing is that this introduces a lot more hardware complexity (which means cost and power) which isn't of any great benefit in most cases. Now that memory is so cheap, using a byte, or even a word, to represent a boolean s no big deal. (Now, when I was young and you only had 2K of RAM ....)

[StringJunky]

Apparently you can buy 1-bit sound recorders. SACD's exploit it.

[Strange]

I had a colleague who worked out that he only needed 1-bit resolution for his digital signal processing application and so was able to process 32 channels in parallel in each word, which meant his software was faster and ran on cheaper hardware than any of the competitors.

[MonDie]

 

There are a few, specialised, architectures that support direct and efficient access to arbitrary bits. The thing is that this introduces a lot more hardware complexity (which means cost and power) which isn't of any great benefit in most cases. Now that memory is so cheap, using a byte, or even a word, to represent a boolean s no big deal. (Now, when I was young and you only had 2K of RAM ....)

 

Okay, yeah. I just compiled a very simple program (below), and it was already more than 8 kilobytes.

#include <iostream>

int main()
{
}

Then used linux's hexdump utility to output the binary of the executable, directing the output into a plain text file on my desktop.

hexdump ./executable >~/Desktop/file

It was a 470 by 9 grid of hexadecimals.

Edited January 21, 2015 by MonDie

[Sensei]

Maybe this will interest you

https://msdn.microsoft.com/en-us/library/yszfawxh.aspx

"C Bit Fields"

Search google for "bit field variable in c"

Couldn't you make more efficient programs if a 3 bit type were available, for example?

Efficiency would be in memory handling, not CPU execution time which would be slower (because of masking and setting bit of byte).

 

CPU cache is also reading/writing entire block of data. So reading in random order array of bytes (f.e. 8000 bytes) is taking as much time as reading f.e. double array (1000 doubles).

You should read about CPU cache for more detail

http://en.wikipedia.org/wiki/CPU_cache

 

Does the obejct (the binary sequence representing variable info, that is) also have to store the name of the variable in addition to its value?

Name of variable is stored only if you not strip symbols in linker settings in your project..

 

But couldn't restrictions be placed on name-sizes, forcing the programmer to rely on re-initialization rather than the creation of independent objects with unique names?

Where do objects with no further importance go to anyway? Would a preference for re-initialization (or re-assignment?) result in smaller object files?

Reading/writing bits like variables will increase executable object size, not reduce it. Additional bit-wise and & and bit-wise or | will have to be included in it.

[MonDie]

Sensei, you point me toward useful concepts, but you would be noticeably more helpful if you elaborated more in your sentences, particularly if you elaborated on terms (f.e. "block of data") or used more standardized terms. In fact, sometimes just saying "Look up terms xxx and yyy" can be more useful than giving your own unprofessional account. Although in the case of programming, one can also benefit greatly from examples of code.

 

Efficiency would be in memory handling, not CPU execution time which would be slower (because of masking and setting bit of byte).

What meaning of "efficiency" would be distinct from CPU execution time?

 

Reading/writing bits like variables will increase executable object size, not reduce it. Additional bit-wise and & and bit-wise or | will have to be included in it.

That's odd. Is it perchance less efficient because non-standard objects, such as masks, result in messier code and thus messier binary code?

Edited January 21, 2015 by MonDie

[Strange]

What meaning of "efficiency" would be distinct from CPU execution time?

 

I think he means using less memory. There is always a trade-off possible between speed and size.

 

That's odd. Is it perchance less efficient because non-standard objects, such as masks, result in messier code and thus messier binary code?

 

Really just that (unless the architecture has hardware support) accessing individual bits requires more instructions, and hence more execution cycles, and this will usually offset the benefits of reducing memory used by accessing single bits.

[Sensei]

Imagine two sample codes:

struct
{
int data1;
int data2;
int data3;
int data4;
int data5;
int data6;
int data7;
int data8;
} x;
x.data1 = true;

...

x.data1 = false;


and

struct
{
int data;
} x;

x.data |= 0x1;

....

x.data &= ~0x1;

Both do the same task. Have array of true/false flags.
First one will generate smaller executable object size, using more memory for x structure, but working faster from CPU point of view (entire x is in CPU cache line in both cases)
Second will generate bigger executable object size, will be using less memory for x structure, but will be working slower.

Sensei, you point me toward useful concepts, but you would be noticeably more helpful if you elaborated more in your sentences, particularly if you elaborated on terms (f.e. "block of data") or used more standardized terms.

 

I gave you link for reading where these things are described with detail I am not able to provide by myself in English language. Not to mention discussion about CPU cache is off-topic.

There is no single CPU cache line size. Different CPUs have different sizes.

Edited January 21, 2015 by Sensei

[MonDie]

That was excellent, Sensei. (Also, Strange's link helped me understand it.)

 

On a forum, it's hard to distinguish someone whose native language is not English from someone who is very young or is autistic.

[Phi for All]

On a forum, it's hard to distinguish someone whose native language is not English from someone who is very young or is autistic.

 

Was that really necessary? Did you really need to say that?