weird usage of "&" for a novice c++ programmer

Question

I have some code here, and don't really understand the ">>" and the "&". can someone clarify?

        buttons[0] = indata[byteindex]&1;
    buttons[1] = (indata[byteindex]>>1)&1;
    rawaxes[7] = (indata[byteindex]>>4)&0xf;

Answer 1

These are bitwise operators. & ands two arguments bit by bit. '>>' shifts first argument's bit string to the right by second argument. '<<' does the opposite. | is bitwise or and ^ is bitwise xor just like & is bitwise and.

Answer 2

These are bitwise operators, meaning they operate on the binary bits that make up a value. See Bitwise operation on Wikipedia for more detail.

& is for AND

If indata[byteindex] is the number 4, then in binary it would look like 00000100. ANDing this number with 1 gives 0, because bit 1 is not set:

00000100 AND 00000001 = 0

If the value is 5 however, then you will get this:

00000101 AND 00000001 = 1

Any bit matched with the mask is allowed through.

>> is for right-shifting

Right-shifting shifts bits along to the right!

00010000 >> 4 = 00000001

Answer 3

The '&' (in this case) is a bitwise AND operator and ">>" is the bit-shift operator (so x>>y yields x shifted right Y bits).

So, they're taking the least significant bit of indata[byteindex] and putting it into buttons[0]. They taking the next least significant bit and putting it into buttons[1].

The last one probably needs to be looked at in binary to make a lot of sense. 0xf is 1111₂, so they're taking the input, shifting it right 4 bits, then retaining the 4 least significant bits of that result.

Answer 4

In English, the first line is grabbing to lowest bit (bit 0) only out of Button[0]. Basically, if the value is odd, it will be 1, if even, it will be 0. (bit 1) The second is grabbing the second bit. If that bit is set, it returns 1, else 0. It could have also been written as

buttons[1] = (indata[byteindex]&2)>>1;

and it would have done the same thing.

The last (3rd) line is grabbing the 5th throuh 8th bits (bits 4-7). Basically, it will be a number from 0 to 15 when it is complete. It also could hav been written as

rawaxes[7] = (indata[byteindex]&0xf0) >> 4;

and done the same thing. I'd also guess from context that these arrays are unsigned char arrays. Just a guess though.

Answer 5

One of the standard patterns for extracting a bit field is (reg >> offset) & mask, where reg is the register (or other memory location) you're reading, offset is how many least-significant bits you skip over, and mask is the set of bits that matter. The >> offset step can be omitted if offset is 0. mask is usually equal to 2^width-1, or (1 << width) - 1 in C, where width is the number of bits in the field.

So, looking at what you have:

buttons[0] = indata[byteindex]&1;

Here, offset is 0 (it was omitted) and mask is 1. So this gets just the least-significant bit in indata[byteindex]:

    bit number ->   7 6 5 4 3 2 1 0
                   +-+-+-+-+-+-+-+-+
indata[byteindex]  | | | | | | | |*|
                   +-+-+-+-+-+-+-+-+
                                  |
                                  \----> buttons[0]

Next:

buttons[1] = (indata[byteindex]>>1)&1;

Here, offset is 1 and width is 1...

    bit number ->   7 6 5 4 3 2 1 0
                   +-+-+-+-+-+-+-+-+
indata[byteindex]  | | | | | | |*| |
                   +-+-+-+-+-+-+-+-+
                                |
                                \------> buttons[1]

And, finally:

rawaxes[7] = (indata[byteindex]>>4)&0xf;

Here, offset is 4 and width is 4 (2⁴-1 = 16 - 1 = 15 = 0xf):

    bit number ->   7 6 5 4 3 2 1 0
                   +-+-+-+-+-+-+-+-+
indata[byteindex]  |*|*|*|*| | | | |
                   +-+-+-+-+-+-+-+-+
                    | | | |
                    \--v--/
                       |
                       \---------------> rawaxes[7]

EDIT...

but I don't understand what the point of it is...

Mike pulls up a rocking chair and sits down.

Back in the old days of 8-bit CPUs, a computer typically had 64K (65 536 bytes) of address space. Now we wanted to do as much as we could with our fancy whiz-bang machines, so we would do things like buy 64K of RAM and map everything to RAM. Shazam, 64K of RAM and bragging rights all around.

But a computer that can only access RAM isn't much good. It needs some ROM for an OS (or at least a BIOS), and some addresses for I/O. (You in the back--siddown. I know Intel chips had separate address space for I/O, but it doesn't help here because the I/O space was much, much smaller than the memory space, so you ran into the same constraints.)

Address space used for ROM and I/O was space that wasn't accessible as RAM, so you wanted to minimize how much space wasn't used for RAM. So, for example, when your I/O peripheral had five different things whose status amounted to a single bit each, rather than give each one of those bits its own byte (and, hence, address), they got the brilliant idea of packing all five of those bits into one byte, leaving three bits that did nothing. Voila, the Interrupt Status Register was born.

The hardware designers were also impressed with how fewer addresses resulted in fewer address bits (since address bits is ceiling of log-base-2 of number of addresses), meaning fewer address pins on the chip, freeing pins for other purposes. (These were the days when 48-pin chips were considered large, and 64-pins huge, and grid array packages were out of the question because multi-layer circuit boards were prohibitively expensive. These were also the days before multiplexing the address and data on the same pins became commonplace.)

So the chips were taped out and fabricated, and hardware was built, and then it fell to the programmers to make the hardware work. And lo, the programmers said, "WTF? I just want to know if there is a byte to read in the bloody serial port, but there are all these other bits like "receiver overrun" in the way." And the hardware guys considered this, and said, "tough cookies, deal with it."

So the programmers went to the Guru, the guy who hadn't forgotten his Boolean algebra and was happy not to be writing COBOL. And the Guru said, "use the Bit AND operation to force those bits you don't care about to 0. If you need a number, and not just a zero-or-nonzero, use a logical shift right (LSR) on the result." And they tried it. It worked, and there was much rejoicing, though the wiser ones started wondering about things like race conditions in a read-modify-write cycle, but that's a story for another time.

And so the technique of packing loosely or completely unrelated bits into registers became commonplace. People developing protocols, which always want to use fewer bits, jumped on these techniques as well. And so, even today, with our gigabytes of RAM and gigabits of bandwidth, we still pack and unpack bitfields with expressions whose legibility borders on keyboard head banging.

(Yes, I know bit fields probably go back to the ENIAC, and maybe even the Difference Engine if Lady Ada needed to stuff two data elements into one register, but I haven't been alive that long, okay? I'm sticking with what I know.)

(Note to hardware designers out there: There really isn't much justification anymore for packing things like status flags and control bits that a driver writer will want to use independently. I've done several designs with one bit per 32-bit register in many cases. No bit shifting or masking, no races, driver code is simpler to write and understand, and the address decode logic is trivially more complex. If the driver software is complex, simplifying flag and bitfield handling can save you a lot of ROM and CPU cycles.)

(More random trivia: The Atmel AVR architecture (used in the Arduino, among many other places) has some specialized bit-set and bit-clear instructions. The avr-libc library used to provide macros for these instructions, but now the gcc compiler is smart enough to recognize that reg |= (1 << bitNum); is a bit set and reg &= ~(1 << bitNum); is a bit clear, and puts in the proper instruction. I'm sure other architectures have similar optimizations.)