Why use hex?

Question

Hey! I was looking at this code at http://www.gnu.org/software/m68hc11/examples/primes_8c-source.html

I noticed that in some situations they used hex numbers, like in line 134:

for (j = 1; val && j <= 0x80; j <<= 1, q++)

Now why would they use the 0x80? I am not that good with hex but I found an online hex to decimal and it gave me 128 for 0x80.

Also before line 134, on line 114 they have this:

small_n = (n & 0xffff0000) == 0;

The hex to decimal gave me 4294901760 for that hex number. So here in this line they are making a bit AND and comparing the result to 0??

Why not just use the number? Can anyone please explain and please do give examples of other situations.

Also I have seen large lines of code where it's just hex numbers and never really understood why :(

Solution 1

In both cases you cite, the bit pattern of the number is important, not the actual number.

For example, In the first case, j is going to be 1, then 2, 4, 8, 16, 32, 64 and finally 128 as the loop progresses.

In binary, that is,

0000:0001, 0000:0010, 0000:0100, 0000:1000, 0001:0000, 0010:0000, 0100:0000 and 1000:0000.

There's no option for binary constants in C (until C23) or C++ (until C++14), but it's a bit clearer in Hex: 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, and 0x80.

In the second example, the goal was to remove the lower two bytes of the value. So given a value of 1,234,567,890 we want to end up with 1,234,567,168.
In hex, it's clearer: start with 0x4996:02d2, end with 0x4996:0000.

Solution 2

its a bit mask. Hex values make it easy to see the underlying binary representation. n & 0xffff0000 returns the top 16 bits of n. 0xffff0000 means "16 1s and 16 0s in binary"

0x80 means "1000000", so you start with "00000001" and continue shifting that bit over to the left "0000010", "0000100", etc until "1000000"

Solution 3

There's a direct mapping between hex (or octal for that matter) digits and the underlying bit patterns, which is not the case with decimal. A decimal '9' represents something different with respect to bit patterns depending on what column it is in and what numbers surround it - it doesn't have a direct relationship to a bit pattern. In hex, a '9' always means '1001', no matter which column. 9 = '1001', 95 = '*1001*0101' and so forth.

As a vestige of my 8-bit days I find hex a convenient shorthand for anything binary. Bit twiddling is a dying skill. Once (about 10 years ago) I saw a third year networking paper at university where only 10% (5 out of 50 or so) of the people in the class could calculate a bit-mask.

Solution 4

0xffff0000 is easy to understand that it's 16 times "1" and 16 times "0" in a 32 bit value, while 4294901760 is magic.

Solution 5

The single biggest use of hex is probably in embedded programming. Hex numbers are used to mask off individual bits in hardware registers, or split multiple numeric values packed into a single 8, 16, or 32-bit register.

When specifying individual bit masks, a lot of people start out by:

#define bit_0 1
#define bit_1 2
#define bit_2 4
#define bit_3 8
#define bit_4 16
etc...

After a while, they advance to:

#define bit_0 0x01
#define bit_1 0x02
#define bit_2 0x04
#define bit_3 0x08
#define bit_4 0x10
etc...

Then they learn to cheat, and let the compiler generate the values as part of compile time optimization:

#define bit_0 (1<<0)
#define bit_1 (1<<1)
#define bit_2 (1<<2)
#define bit_3 (1<<3)
#define bit_4 (1<<4)
etc...

View more solutions

Comments

[Lawrence Hutton]

Minor correction on the second example: It removes the lower two bytes of a four-byte number. Removing the lower four bytes would simply be "small_n = 0;".

[James Curran]

D'Oh! Ya'know, I was debating between writing "4 digits" and "two bytes", so naturally I conflated them into a wrong statement.....

[Kibbee]

There's nothing wrong with that code. Looking at that code, I couldn't find a more clear way to write it without using HEX.