ansaurus

Question

My bit logic is too outdated. Refresher needed

Answer 1

+8 A:

First of all convert the input number to hexadecimal:

19444 => 0x4BF4

Hex is convenient because every 4 binary bits are one hex digit. Hence, every 2 hex digits are 8 bits, or a byte. Now assuming traditional little-endian notation (look it up!), bits 7 downto 0 are the low byte, bits 15 downto 8 are the high byte:

   [7:0] => 0xF4
   [15:8] => 0x4B

Eli Bendersky 2010-07-15 05:14:10

+1 for explaining things.

Kobi 2010-07-15 05:23:52

Endianness is irrelevant (unless you're accessing individual bytes using pointer or union magic - which may be happening if this stuff is coming from a serial line etc.).

Artelius 2010-07-15 05:25:22

@Artelius: I beg to differ. With some interpretations of endinaness, [7:0] (or rather [0:7]) would be the high byte. It is **very** relevant

Eli Bendersky 2010-07-15 05:40:47

@Eli - can you give an example? In my experience, bits 0..7 are always the least significant byte - it's only the position of that byte in memory that varies based on endianness. If that's wrong, I'd like to know how much I need to worry about it.

Steve314 2010-07-15 06:13:51

@Steve314: some processors specify their words as reg[0:31], where bits [0:7] are the high byte of the register and so on

Eli Bendersky 2010-07-15 06:47:34

After doing some reading it seems Eli is right (http://en.wikipedia.org/wiki/Bit_numbering), but it seems braindead to me. IMO bits should always be numbered based on the power of 2 of their place value; this would greatly reduce complications resulting from endianness and word size.

Artelius 2010-07-15 06:51:22

@Artelius: it's called "endianness" for a reason - a pun made by Johnathan Swift in his Gulliver books on the "brain-dead" debates about the end of the egg from which to start eating it. :-)

Eli Bendersky 2010-07-15 07:09:25

@Eli - "Some processors" isn't an example. But from Artelius comment, I guess you're right.

Steve314 2010-07-15 07:10:23

Answer 2

+3 A:

Using your preferred language, you can get the least significant byte by using a bitwise AND:

Y = 19444 & 0xff

or, the more mathematical:

Y = 19444 % 256

Now, for the most significant byte you can use bit shifts (if the number is larget than two byte, apply the first stage again):

X = 19444 >> 8

Kobi 2010-07-15 05:23:27

Answer 3

+1 A:

Also, mind the byte order (wheter the most significant byte comes first).

2010-07-15 05:26:58

Not in this case. *Bit* numbering might be relevant though.

Paul R 2010-07-15 05:32:30

Byte order is not relevant here as there has been no mention of memory addresses.

Artelius 2010-07-15 05:33:51

Answer 4

+1 A:

When given bit positions (like "15 through 8"), by convention bit 0 is the least significant bit of the binary number. If you're dealing with a 16-bit number, then bit 15 is the most significant bit.

One hexadecimal digit corresponds to 4 binary digits. So hex FF is 11111111 in binary. Bitwise AND is often used to "mask out" a certain collection of bits.

Nearly all processors provide some form of bitwise shifting. For example, shifting 1010001 right by 4 bits gives you 101.

Combining all this, in C you would typically do something like this:

unsigned short int num;
unsigned char x, y;

num = 19444;

y = num & 0xff; //use bitwise AND to get 8 least-sig bits
x = num >> 8;   //right-shift by 8 bits to get 8 most-sig bits

Artelius 2010-07-15 05:31:33

Answer 5

+3 A:

(The following assumes C notation). In general, to access the value in bits N through M, where N is the smaller value and the bits are numbered from 0, use:

(value >> N) & (1U << (M - N + 1)) - 1;

So for bits 0..7, use:

(value >> 0) & (1U << 8) - 1

and for bits 8..15, use:

(value >> 8) & (1U << 8) - 1

Note that for the case where "N through M" is the entire width of the type, you can't use the shift as written.

caf 2010-07-15 05:33:16

ansaurus

tags:

views:

answers:

My bit logic is too outdated. Refresher needed

related questions