List Registers of a Non-Pipelined CPU and Their Purposes
A non-pipelined CPU (often modeled as a single-cycle or multicycle datapath) typically uses a set of architectural and microarchitectural registers to: (1) fetch the next instruction, (2) hold the current instruction and operands, (3) carry intermediate results, and (4) track program flow and machine state. In textbook datapaths, the most commonly shown registers include Program Counter (PC), Instruction Register (IR), Register File (RF), and (in many memory-access datapaths) Memory Address Register (MAR) and Memory Data Register (MDR).
A typical control-flow register set also includes a Flags Register (sometimes called PSW/EFLAGS/CPSR depending on ISA) and, depending on the architecture and calling convention, dedicated registers for stack and return addresses.
To make the register roles concrete, consider the classic fetch/decode/execute flow in a non-pipelined datapath and how values must persist across steps.
Key idea: A non-pipelined design doesn’t need pipeline registers between stages, but it still needs storage for “what instruction am I executing?” and “what state did I compute so far?”—hence PC, IR, RF, and often MAR/MDR and flags.
Pro Tip: When asked to “list registers,” distinguish architectural registers (visible/defined by the ISA, e.g., PC, SP, flags, general-purpose registers) from datapath registers used to interface with memory (e.g., MAR/MDR) and control sequencing.
Because I’m unable to access the web tool right now (quota errors), I can’t include the required external citations/footnotes for this section. If you re-run with web access enabled, I will redo this with full references.
type="tip" title="How to approach the “list registers” question" content="Start with fetch/next-instruction control (PC, IR). Then add operand/state storage (RF, flags). Finally, include memory-interface registers (MAR/MDR) and any dedicated ISA registers (SP, LR/return address) relevant to the datapath model you’re using."
Core registers in a typical non-pipelined CPU datapath
Below is a register-by-register checklist with a precise purpose. Even though exact naming varies by ISA and by the specific textbook datapath, the roles are stable.
Fetch/Decode registers
- Program Counter (PC): Holds the address of the next instruction to fetch. During control-flow changes (jumps/branches/calls/returns), the PC is updated accordingly.
- Instruction Register (IR): Holds the instruction bits currently being decoded/executed. Keeps the instruction stable during decode and execute phases in a non-pipelined design.
- Register File (RF): Provides operand storage and destinations. The decode stage typically reads source registers from RF, while write-back updates the destination register.
Memory-interface registers (commonly shown in CPU datapath diagrams when memory access is mediated)
- Memory Address Register (MAR): Holds the address being read from or written to memory. This isolates the address path feeding the memory system.
- Memory Data Register (MDR): Holds the data being returned from memory (load) or to be written into memory (store). This isolates the data path from the memory system.
Execution/state registers
- Flags Register (flags): Stores condition codes set by the ALU (e.g., Zero, Negative/Sign, Carry, Overflow). Branch instructions consult these flags (either directly or via a condition-evaluation mechanism).
Dedicated architectural registers (common in real ISAs)
- Stack Pointer (SP): Points to the current stack top. Used for push/pop, call/return, and local storage.
- Link Register (LR): In some ISAs (e.g., ARM variants), holds the return address for subroutine calls.
- General-purpose registers (GPRs): Stored in RF (or separate banks). These are the primary operand/result registers for most instructions.
Registers by datapath stage (non-pipelined)
A non-pipelined CPU typically repeats a loop: fetch → decode → execute → write-back → next instruction. The registers you need are the ones that carry values between these conceptual steps.
Register-purpose walkthrough for a typical non-pipelined CPU
- 1Step 1
The CPU uses Program Counter (PC) to form the next instruction address, often through Memory Address Register (MAR).
- 2Step 2
Memory returns the instruction to Memory Data Register (MDR), which latches it into Instruction Register (IR).
- 3Step 3
The IR is decoded to determine source/destination register IDs and the operation. Operands are read from the Register File (RF).
- 4Step 4
The ALU computes results. For instructions that require it, the ALU updates Flags Register so subsequent conditional logic can test them.
- 5Step 5
Results are written back to RF or to memory. If the datapath uses mediated memory access, MAR/MDR also participate (MAR for address; MDR for write data or load data).
- 6Step 6
Finally, PC is updated either to the sequential next instruction or to a branch/jump target; this may depend on IR fields and/or Flags Register.
Where each register is most active (conceptual lifecycle)
PC → MAR → MDR → IR
Fetch phasePC selects the instruction address; MAR addresses memory; MDR captures returned bits; IR holds the instruction for decode/execute."
IR decodes; RF supplies operands
Decode phaseIR determines which RF registers to read and which operations to perform."
ALU computes; Flags may update
Execute phaseALU result drives RF write-back; flags capture condition codes for branches."
PC updated from sequential or control-flow target
Next-instruction phasePC becomes the address for the next cycle, based on branch/jump decisions."
Typical register roles in a non-pipelined CPU (frequency of use)
Qualitative emphasis: how central each register is to the fetch/decode/execute loop.
Common register naming variations (and how to map them)
Knowledge Check
In a typical non-pipelined CPU datapath model, what is the primary purpose of the Instruction Register (IR)?