How the CPU Distinguishes Instructions from Image Data: Fetch Paths and Decoding Rules

01 The Same Byte Can Be an Instruction or Data

A single byte 10010000 (hex 0x90, decimal 144) illustrates the point. In x86, if the CPU fetches this byte as an instruction, it decodes to NOP (no operation). If software treats it as an 8‑bit grayscale sample, it represents pixel value 144. The byte itself does not change; the interpretation depends on the fetch path and the decoding rules applied.

Even within an instruction stream, 0x90 might appear as an immediate operand or part of a multi‑byte opcode — it is not a standalone NOP unless the decoder starts at that exact address. Conversely, program files can be copied, compressed, or checksummed by other programs that treat the machine code as ordinary data.

02 CPU Instruction Fetch: The Program Counter (PC/RIP)

The CPU tracks the next instruction address in a register called the program counter (PC) (x86‑64 uses RIP ). A simplified model: PC points to an address, the CPU fetches bytes from there, decodes them according to the current instruction set and execution mode, and executes the resulting operation.

If the decoded instruction requires a memory read (e.g., mov al, [0x3000]), a second memory access occurs. The two accesses serve different purposes:

Fetch from 0x1000 → instruction bytes enter the instruction decode path .

Read from 0x3000 → byte 0x90 enters a register as data for subsequent processing.

The CPU does not inspect 0x90 to decide whether it looks like an image; the instruction that initiated the read already defined the access as a data load. Sequential execution increments the PC; jumps, calls, and returns change it. Real CPUs add caches, prefetch, pipelines, and out‑of‑order execution, but the logical distinction between instruction fetch and data access remains.

03 Who “Understands” the Image?

Opening a PNG invokes a decoder program. The decoder (running as machine instructions) parses the file structure, extracts dimensions, color type, etc., then decompresses and unfilters the byte stream to produce pixel buffers. The CPU executes the decoder’s instructions — reading bytes, computing, branching, writing pixels. The image bytes are data processed by that program. File extensions merely hint at the format; the decoder must still validate the content, and the CPU’s instruction decoder never switches to an “image mode” because of a .png suffix.

04 Placing Code and Data in Memory: OS Loader and Page Permissions

At program start, the OS loader reads the executable file (e.g., ELF) and creates memory mappings with appropriate permissions: code pages typically read + execute , data pages (like image buffers) read + write but not execute . Hardware mechanisms such as NX/XD enforce the execute‑disable bit.

Crucially, “executable” is a permission, not a content certification . Code pages may contain constants or padding; the OS does not verify every byte is a valid instruction. The actual execution flow and instruction‑set rules determine what gets decoded and executed.

05 What If the CPU Fetches Instructions from Image Data?

If a bug or exploit redirects the PC into an image buffer, two checks apply:

Execute permission: If the page is non‑executable, the fetch triggers a protection fault (e.g., SIGSEGV on Linux).

Valid encoding: If the page is executable, the CPU attempts to decode the bytes. Invalid opcodes raise an illegal‑instruction exception; valid opcodes execute, potentially causing erratic behavior or later faults. The byte 0x90 again shows that image data can coincidentally be valid instructions.

Protection mechanisms check access rights ; the decoder checks encoding validity . Neither examines whether the bytes originated from a photograph.

06 Summary

The CPU distinguishes instruction fetch from data access via the PC, instruction‑set encoding rules, the running program’s logic, and memory‑page permissions. When you view a photo, the CPU follows the decoder program’s instruction stream; the image bytes are read, transformed into pixels, and passed to the display pipeline. The CPU does not judge 0s and 1s by their “appearance”; the meaning of an image is constructed by software following format specifications.