Data Representation: Bits That Mean Something

In the previous article, Pipeline and Buses, we saw how the CPU executes multiple instructions in parallel and how buses carry information between components. But what is that information? To the hardware, everything is bits: high and low voltages, zeros and ones. The difference between a character, a negative integer, and a floating-point number lies exclusively in the interpretation convention, in the way we agreed that a bit pattern should be read.

This choice also shapes the physical design of the chip. The number of bits we choose to represent a piece of data directly dictates the width of the data bus, the capacity of the registers, and the complexity of the ALU. The first of these conventions we need to understand does not deal with heavy math, but with the way the computer learned to read and write with us: text.

This article walks through these fundamental conventions: the standards for representing text (ASCII, Unicode, UTF-8), the three methods for signed integers (and why two’s complement took over), bit shifts, and the IEEE 754 standard for real numbers. Understanding these representations is essential to understand why 0.1 + 0.2 ≠ 0.3 in programming and how negative numbers work in hardware.

This article, then, serves as an integrated summary of these concepts, focused on the computer architecture perspective.

Character representation

#

How do we represent letters, digits, and symbols as bits? For that, the computer uses a character encoding: a convention that associates symbols with numbers.

It is important to separate three ideas that sometimes show up mixed together:

• character code: the table of symbols;
• code point: the abstract number associated with a character;
• encoding: the concrete way of storing that code point in bytes.

ASCII, Latin-1, and the 8th bit

#

ASCII (American Standard Code for Information Interchange) uses 7 bits and represents 128 symbols. It includes:

• control characters (0 to 31 and 127, the DEL);
• printable characters (32 to 126), such as letters, digits, and punctuation.

Historically, in many systems the 8th bit of the byte could be used as a parity bit to detect transmission errors. In other contexts, that bit came to be used for 8-bit extensions, such as Latin-1, making it possible to represent accented characters and additional symbols.

It is worth seeing the table at work with concrete numbers, because this is where the encoding stops being an abstraction:

Two things jump out of this table. The first is that digits start at 0x30, which turns the conversion from character to number into a subtraction: '7' - '0' = 7. The second is prettier, and it is exactly the theme of this article:

Uppercase and lowercase versions of the same character differ by a single bit: bit 5. 'A' is 0100 0001 and 'a' is 0110 0001; the bit of weight 32 changes and nothing else. That is why changing the case of an ASCII letter needs no table at all, only a bitwise operation: c ^ 0x20 toggles between uppercase and lowercase, c | 0x20 forces lowercase, and c & 0xDF forces uppercase. The ASCII table was not ordered by chance; this regularity was designed.

Unicode and the UTF encodings

#

Unicode should not be understood as a fixed 16-bit encoding, but as a universal repertoire of code points. Its code space goes from U+0000 to U+10FFFF.

To store these code points in memory or in files, we use encodings such as:

So the right way to think about it is:

• Unicode = repertoire of characters;
• UTF-8 / UTF-16 / UTF-32 = ways of encoding that repertoire.

How UTF-8 organizes the bits

#

Saying that UTF-8 uses “1 to 4 bytes” leaves out the interesting part: how the program knows how many bytes to read. The scheme is a convention of leading bits, and it is the same bit-field idea that the whole article has been dealing with:

The x are the bits of the code point, filled from right to left. The rest is signaling: a byte that starts with 0 is pure ASCII; one that starts with 110 announces “I am the first of two”; and every continuation byte starts with 10.

From this comes the property that made UTF-8 win: it is self-synchronizing. Since no continuation byte can be mistaken for a leading byte, a program that lands in the middle of a text can find the start of the next character by walking backward until it finds a byte that does not start with 10. Many earlier variable-length encodings, such as Shift-JIS, did not have this.

An example with ç, code point U+00E7:

• U+00E7 in binary is 1110 0111, with 8 bits, so it falls in the 2-byte range;
• the 11 bits of the template receive 000 1110 0111;
• first byte: 110 + 00011 = 1100 0011 = 0xC3;
• second byte: 10 + 100111 = 1010 0111 = 0xA7.

That is, ç in UTF-8 is the bytes 0xC3 0xA7, and that is why a UTF-8 file read as Latin-1 shows ç in place of ç: the two bytes show up as two separate characters.

For the full story of this confusion, the canonical reference is The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), by Joel Spolsky.

Unsigned integers

#

For unsigned integers, the representation is direct: each bit corresponds to a power of 2, from the LSB (least significant bit, \(b_0\)) to the MSB (most significant bit):

Example: \(10110101_2\):

Binary ↔ hexadecimal conversion

#

Hexadecimal works as a compact notation for binary: group the bits in fours, from right to left, and convert each group to its equivalent hexadecimal digit (0 to 9, A to F).

Check: \(\text{5A}_{16} = 5 \times 16 + 10 = 80 + 10 = 90_{10}\) ✓

Signed integers

#

Representing negative numbers requires an additional convention. Throughout history, three methods have been used:

Sign and magnitude

#

The MSB indicates the sign (0 = positive, 1 = negative); the remaining \(n-1\) bits represent the magnitude. Range: \(-(2^{n-1}-1)\) to \(+(2^{n-1}-1)\). The fatal problem: two zeros (\(+0 = 0000\ 0000\) and \(-0 = 1000\ 0000\)) complicate comparison and arithmetic circuits.

One’s complement (C1)

#

The negative of a number is obtained by inverting all the bits. The result for \(-5\) in 8 bits: \(+5 = 0000\ 0101 \Rightarrow -5 = 1111\ 1010\). The arithmetic becomes simpler than in sign and magnitude, but the two-zeros problem remains (\(0000\ 0000\) and \(1111\ 1111\)). C1 is rarely used in modern systems.

Two’s complement (C2): the modern standard

#

The negative is obtained by inverting all the bits and adding 1 to the result. C2 has only one zero, and subtraction reduces to addition: the ALU hardware needs only one adder to perform both operations.

With the three methods defined, it is worth seeing them read exactly the same bits. The figure below does this with three bytes. The first, positive, gives the same value in all three schemes. The second shows the central point of this article: the same byte becomes three different numbers, because the value is not in the bits, it is in the convention used to read them. And the third, 1000 0000, is the edge case: a repeated zero in sign and magnitude, the smallest negative of one’s complement, and the \(-128\) that only two’s complement can represent.

Operations in two’s complement

#

How to compute the C2 of a number (negation)

#

The algorithm has three steps:

1. 1

   Write in binary

   Write the number in binary.
2. 2

   Invert the bits

   Invert all the bits, obtaining the one’s complement.
3. 3

   Add 1

   Add 1 to the result.

Check (\(+5 + (-5)\) must be zero):

Subtraction as addition: \(A - B = A + C2(B)\)

#

To understand how this works in practice, let us simulate the operation 5 - 3. Following the formula above, we set \(A = 5\) and \(B = 3\). Instead of using a dedicated circuit to subtract, the CPU computes the two’s complement of 3 (obtaining the bit representation of -3) and adds that value directly to the number 5. The following table details this process step by step using 8 bits:

Detecting overflow

#

If this part about overflow was hard for you, we have a whole article dedicated to it in the series From Zero to Float, where we explain the concept of overflow in detail, with examples and exercises.

Bit shifts

#

Two’s complement also lets the hardware use mathematical “shortcuts”. The most efficient possible operation to multiply or divide by powers of 2 does not engage complex adders, but rather bit shifts: an operation solved by “pushing” bits sideways in a single ALU cycle.

The MSB copy works as follows: if the number is positive (MSB = 0), the right shift fills with 0, keeping the result positive. If the number is negative (MSB = 1), the shift fills with 1, preserving the negative sign. This makes the arithmetic right shift behave like an integer division by 2, rounding down, even for negative numbers. For example: \(-3\) in 8 bits is 1111 1101. Shifting right arithmetically gives 1111 1110, because the MSB is 1, indicating a negative number, and 1 is inserted on the left to keep the sign. The result is \(-2\), which is the expected result of \(-3\) divided by 2, rounding down.

Examples in 8 bits:

Arithmetic right shift: careful with the interpretation

#

The arithmetic right shift is often presented as a quick way to “divide by 2” signed integers. This is useful as intuition, but deserves a remark:

• for unsigned integers, the logical right shift is equivalent to integer division by 2;
• for signed integers in two’s complement, the arithmetic right shift preserves the sign bit, which makes the result behave like a rounding down in many negative cases.

So it is worth stating carefully: the arithmetic right shift is a hardware operation that, in two’s complement, usually corresponds to integer division by a power of 2, preserving the sign. “Usually” because the rounding is not the same as the language’s division: the shift rounds down (toward \(-\infty\)), while the integer division operator of many languages rounds toward zero. For \(-13\) in 8 bits, the 2-bit shift gives \(-4\); in C, -13 / 4 gives \(-3\).

Floating point: the IEEE 754 standard

#

Although two’s complement integers are perfect for exact counting and memory manipulation, the physical world (with its microscopic distances and astronomical quantities) demands a flexibility that fixed bits cannot offer. For continuous quantities, we need approximate real numbers. Floating point solves this by using a normalized scientific notation in base 2:

where \(S\) is the sign bit (0 = positive, 1 = negative), \(E\) is the integer exponent, and the significand is the fractional bits after the implicit 1..

But where do the rules for storing this in bits come from? Historically, each computer manufacturer created its own way of representing floating-point numbers, which caused chaos: the same scientific calculation gave different results depending on which brand of computer ran it. To unify the industry, the IEEE (Institute of Electrical and Electronics Engineers, the world’s main standardization organization for electrical engineering and computing) published the IEEE 754 standard in 1985.

The original IEEE 754 standard defined exactly the basic single and double precision formats, establishing only minimum requirements for “extended” formats. The following table shows the 32-bit and 64-bit formats defined in the standard, in addition to the famous 80-bit extended format (an Intel/x86-specific implementation that meets the standard’s extended format requirements):

The exponent is stored with a bias: the real value is the stored one minus the bias, which allows representing negative exponents without a sign bit of their own. The 1 bit to the left of the point is implicit in single and double: it does not need to be stored, which adds an extra bit of effective precision (24 bits in single, 53 bits in double). In the extended format (80 bits), on the other hand, this leading integer bit is explicit and must be stored, taking up real space and resulting in exactly 64 bits of precision in the significand. Nowadays, the 80-bit extended format is widely considered legacy: it was the internal standard of the old math coprocessors (x87 FPU) of the x86 architecture. Modern processors generally perform floating-point calculations using vector registers (SSE/AVX) optimized for the single and double formats. However, extended is still supported on current processors for backward compatibility (often being mapped to the long double type in C/C++ compilers on the x86 architecture).

Below, the bit structure for the IEEE 754 single precision format (32 bits), where the sign bit is the most significant (MSB), followed by the biased exponent and the fractional significand:

 31  30        23 22                       0
 ┌───┬──────────┬──────────────────────────┐
 │ S │ Exponent │       Significand        │
 │ 1 │  8 bits  │         23 bits          │
 └───┴──────────┴──────────────────────────┘

Special cases

#

IEEE 754 reserves specific patterns for edge situations:

Converting to IEEE 754 single precision

#

flowchart TD
    A["Signed decimal number"] --> B["1. Convert to binary"]
    B --> C["2. Normalize: 1.xxx × 2^E"]
    C --> D["3. Sign bit S
0 = positive, 1 = negative"]
    C --> Exp["4. Biased exponent
E_real + 127"]
    C --> Mant["5. Significand
bits after the implicit 1
(pad with zeros on the right)"]
    D --> R["Result: S | Exponent | Significand"]
    Exp --> R
    Mant --> R

Applying it to the example \(-5.75\):

Check:

Python bonus: inspecting bit representations

#

Python offers direct tools to inspect how numbers are stored in bits, using the struct module (for floating point) and the << and >> operators (for integers).

import struct

# IEEE 754 single precision representation of -5.75
raw = struct.pack(">f", -5.75)          # ">f" = big-endian single float
print(f"-5.75 as bytes   : {raw.hex()}")
# c0b80000

bits = int.from_bytes(raw, "big")
print(f"In binary (32)   : {bits:032b}")
# 11000000101110000000000000000000
# S=1 | Exp=10000001 | Mant=01110000000000000000000 ✓

# Unpacking back
value = struct.unpack(">f", raw)[0]
print(f"Back to float    : {value}")
# -5.75 ✓

# Shifts and two's complement with Python integers
a = 0b00110010  # +50 in decimal
b = 0b11010000  # in 8 bits unsigned = 208, in C2 = -48

print(f"\na = {a}  ({a:08b})")
print(f"a << 1 = {a << 1}  ({a<<1:08b})  (× 2)")
print(f"a >> 1 = {a >> 1}  ({a>>1:08b})  (÷ 2)")

# Two's complement in Python (Python uses arbitrary-precision integers)
def c2_negation(n: int, bits: int = 8) -> int:
    """Return -n in two's complement representation with 'bits' bits."""
    mask = (1 << bits) - 1          # 0xFF for 8 bits
    return (~n & mask) + 1

print(f"\n-50 in C2 (8 bits) : {c2_negation(50):08b} = {c2_negation(50)}")
# 11001110 = 206 (unsigned) or -50 (C2)

# Addition truncated to 8 bits
def c2_add(a: int, b: int, bits: int = 8) -> int:
    mask = (1 << bits) - 1
    return (a + b) & mask

print(f"50 + (-48) in 8 bits: {c2_add(a, b):08b} = {c2_add(a, b)}")
# 00000010 = 2 ✓

# Checking -5.75 as a double (64 bits)
raw64 = struct.pack(">d", -5.75)
bits64 = int.from_bytes(raw64, "big")
print(f"\n-5.75 double (64 bits): {bits64:064b}")
# 1 10000000001 0111000000000000000000000000000000000000000000000000

Conclusion and next articles

#

Bits alone have no meaning: meaning emerges from the interpretation convention. ASCII turns 7 bits into a character; two’s complement turns a bit pattern into a negative integer; IEEE 754 turns 32 bits into a single-precision fractional number. Understanding these conventions is understanding how the computer works.

In the next article, we will explore the representation of machine instructions: how the bit patterns make up the instructions the CPU executes, the different instruction formats, and the addressing modes that determine where to fetch the operands. Understanding data representation is the fundamental step toward understanding instruction representation, since instructions are also just bit patterns, but with a specific structure that the hardware interprets to perform operations.

See you then!