How Computers Represent Numbers and Encode Instructions in Binary

Underneath every value a program manipulates and every instruction a processor executes lies a fixed-width string of bits. This article explains how signed and unsigned numbers are represented and interpreted differently from the same binary pattern, and how machine instructions themselves are encoded into rigid binary fields that hardware can decode at high speed.

Signed and Unsigned NumbersTwo's ComplementInstruction Encoding

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱۵ شهریور ۱۴۰۵

Why Numbers Need a Fixed Representation

Computer hardware stores every value using a fixed number of bits, commonly grouped into 32-bit or 64-bit chunks called Words. Because the number of bits is fixed, there is a hard limit on the range of values that can be represented, and the same bit pattern can mean different things depending on how it is interpreted.

Unsigned Numbers: Representing Only Non-Negative Values

An Unsigned Number uses every available bit to represent magnitude, with no bit reserved for sign. For an n-bit unsigned number, the representable range is:

Range: 0 to (2^n − 1)

Unsigned representation is commonly used for values that can never logically be negative, such as memory addresses.

Signed Numbers and Two's Complement

Most arithmetic in real programs requires negative values as well. The representation used almost universally in modern hardware is called Two's Complement.

In two's complement representation, the leftmost bit is called the Sign Bit: it is 0 for non-negative numbers and 1 for negative numbers, but unlike simple sign-magnitude representation, the remaining bits are not just a plain magnitude — the whole pattern is calculated in a way that makes addition and subtraction work correctly using the same hardware circuitry regardless of sign.

To negate a number in two's complement, every bit is inverted and then 1 is added to the result:

Step 1: Invert all bits of the number
Step 2: Add 1 to the inverted result

This method is chosen specifically because it allows the same adder circuit used for unsigned addition to correctly handle subtraction and negative numbers, avoiding the need for separate hardware.

How Machine Instructions Are Encoded

Just as numeric data is stored as fixed-width binary patterns, instructions themselves are encoded the same way. Each RISC-V instruction is packed into a fixed 32-bit word, divided into distinct Fields, each carrying a specific piece of information.

A typical arithmetic instruction format includes fields such as:

  • Opcode: identifies which basic operation category the instruction belongs to.
  • Destination Register (rd): specifies where the result will be stored.
  • Source Registers (rs1, rs2): specify where the input operand values come from.
  • Funct Fields: provide additional bits needed to fully distinguish the exact operation when the opcode alone is not specific enough.

This layered field structure is called the instruction's Format, and RISC-V defines a small number of standard formats so that decoding hardware can extract each field using the same fixed bit positions across many different instructions, keeping the decoding logic simple and fast.

Why Fixed-Width Encoding Matters

Keeping every instruction the same fixed width, with fields always located at predictable bit positions, allows the processor's decoding hardware to extract operands and identify the operation in a single, simple step rather than needing variable and complex parsing logic — directly supporting the earlier design principle of keeping the common case fast.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Common Misconceptions About Parallel Computing and the Book's Final Lessons

After covering everything from thread-level parallelism to warehouse-scale computing, it is worth correcting persistent misconceptions about parallel systems that even experienced engineers sometimes hold. This article addresses common fallacies about scaling and parallel hardware, then closes out the parallel processing chapter by tying together the full journey from a single instruction to a building full of cooperating machines.

ادامه

Real Stuff: Benchmarking CPUs Against GPUs and Multiprocessor Matrix Multiply

Comparing a CPU and a GPU fairly requires a model that accounts for both computational throughput and memory bandwidth limits together. This article introduces the roofline model used to compare real hardware like the Intel Core i7 and NVIDIA Tesla GPU, then shows how matrix multiplication is accelerated across multiple processors as the final practical application of this chapter's parallel concepts.

ادامه

Benchmarking Multiprocessors and Modeling Parallel Performance

Measuring the performance of a parallel system requires different tools and metrics than measuring a single-core processor. This article covers the specialized benchmarks used to evaluate multiprocessor systems, explains how to model scaling behavior as more processors are added, and revisits Amdahl's Law in the context of real-world performance measurement.

ادامه

Cluster Networking: Connecting to the World Outside

A cluster of machines is only useful if it can communicate efficiently both internally and with the outside world. This article covers the networking layers involved in cluster communication, the tradeoffs between latency and bandwidth at scale, and how clusters connect to external networks and users.

ادامه

Clusters, Warehouse-Scale Computers, and Network Topologies

Beyond a single chip, parallelism extends to entire buildings full of independent computers working together. This article explains the shift from shared memory multiprocessing to clusters of separate machines, introduces the concept of warehouse-scale computing, and covers the network topologies that connect these independent machines efficiently.

ادامه

An Introduction to GPUs: Massive Parallelism for Data-Heavy Workloads

A GPU takes the SIMD idea covered earlier in this series to an extreme scale, running thousands of lightweight threads simultaneously to process massive amounts of independent data. This article explains why GPUs are architecturally so different from CPUs, how their thread execution model works, and what kinds of workloads benefit most from this design.

ادامه