1. The Chasm Between Electrons and Applications

How do we get from physics to photo editing?

The fundamental problem of computing is one of translation across a vast chasm of complexity. At the bottom, we have physics: electrons moving through silicon, transistors switching on and off. At the top, we have applications: your web browser, a video game, a neural network identifying a cat. How do we bridge this gap? We do it with layers of abstraction. The physicist hands a transistor to the circuit designer. The circuit designer hands a logic gate to the microarchitect. The microarchitect hands a processor to the computer architect. And the computer architect hands a machine to the programmer. Our focus is that crucial handoff, the one governed by computer architecture. This is the contract between hardware and software. If we get this contract wrong, the consequences are severe. Programs run slowly, energy is wasted, and systems become insecure. Hardware vulnerabilities like Spectre and Meltdown were not bugs in any single program, but fundamental flaws in the architectural contract itself. Understanding this layer is not optional; it is essential for building efficient, reliable, and secure systems.

• The microarchitect hands a processor to the computer architect
• The fundamental problem of computing is one of translation across
• The physicist hands a transistor to the circuit designer
• The circuit designer hands a logic gate to the microarchitect
• The computer architect hands a machine to the programmer

2. The ISA: A Contract Between Hardware and Software

Architecture is the 'what,' not the 'how.'

So what, precisely, is computer architecture? The classic definition, articulated by Amdahl, Blaauw, and Brooks in their work on the IBM System/360, is that architecture is the programmer-visible interface. More formally, we can break it into three components. First, and most importantly, is the Instruction Set Architecture, or ISA. This is the vocabulary of the machine: the set of commands the hardware understands, the registers it provides for temporary storage, and the way it addresses memory. Second is the microarchitecture, or computer organization, which is the specific implementation of that ISA. We'll see later why this distinction is critical. Third is the system design, which encompasses the rest of the hardware: the memory system, buses, and I/O devices. For the next few weeks, our focus will be squarely on the ISA. Think of the ISA as a formal contract. It is the set of rules the software developer must follow, and the set of capabilities the hardware designer must provide. It is the stable ground upon which the chaotic, ever-changing worlds of hardware and software can meet.

• Is the Instruction Set Architecture, or ISA
• Vocabulary of the machine: the set of commands the hardware understands
• Is the system design, which encompasses the rest of the hardware
• Is the microarchitecture, or computer organization
• The classic definition, articulated by Amdahl, Blaauw

3. From Babbage's Engine to Von Neumann's Draft

The idea that changed everything: instructions are just data.

The conceptual seeds were planted in the 1830s by Charles Babbage with his Analytical Engine, a mechanical computer that, on paper, had all the key elements: an arithmetic 'mill,' a data 'store,' and programmed input via punch cards. But the electronic era began in earnest with machines like ENIAC. ENIAC was an electronic marvel, but it had a crippling limitation: it was programmed by physically re-plugging cables and setting switches. To change the program was a multi-day effort. The breakthrough came in 1945. In his paper, "First Draft of a Report on the EDVAC," John von Neumann—building on the work of his ENIAC colleagues J. Presper Eckert and John Mauchly—laid out the blueprint for the modern computer. The revolutionary idea was the stored-program concept. Instead of being part of the wiring, the program's instructions would be stored in memory, right alongside the data. This meant instructions could be read, written, and modified just like data. This single, elegant idea transformed computers from single-purpose calculators into the universal, programmable machines we know today.

• The breakthrough came in 1945. In his paper
• Instead of being part of the wiring
• The electronic era began in earnest with machines like ENIAC
• Presper Eckert and John Mauchly—laid out the blueprint for the modern
• This meant instructions could be read, written

4. The Fetch-Decode-Execute Cycle

The heartbeat of every modern processor.

The Von Neumann architecture operates on a simple, relentless loop: the fetch-decode-execute cycle. This is the fundamental process by which a computer runs a program. It begins with the 'Fetch' stage. The processor contains a special register called the Program Counter, or PC, which holds the memory address of the next instruction to be run. The control unit fetches the instruction from that memory address and places it into another register, the Instruction Register, or IR. It then increments the PC to point to the next instruction in sequence. Next is the 'Decode' stage. The control unit examines the instruction in the IR. It breaks it down into its constituent parts: the operation code, or 'opcode,' which specifies what to do, and the operands, which specify the data or registers to do it with. Finally, the 'Execute' stage. The instruction is carried out. This could mean sending values to the Arithmetic Logic Unit, or ALU, to be added. It could mean moving data from a register to a memory location. Or it could be a control-flow instruction, like a jump, which changes the Program Counter to a new, non-sequential address. This cycle, repeated billions of times per second, is what gives the illusion of complex, continuous computation.

• The Von Neumann architecture operates on a simple
• The processor contains a special register called the Program Counter
• The control unit fetches the instruction from that memory address
• Or it could be a control-flow instruction
• The fundamental process by which a computer runs a program

5. Decoding an Instruction

The anatomy of a single machine command.

Let's make this concrete by looking at the syntax of a single instruction in a simple, RISC-style ISA. Consider the command: ADD R3, R2, R1. This is human-readable assembly language. It instructs the processor to take the value in register R1, add it to the value in register R2, and store the result in register R3. But the hardware doesn't see these letters. It sees a binary encoding, a fixed-width string of bits. This 32-bit word is broken into fields. The 'opcode' field is a specific bit pattern that signifies the ADD operation. The 'rs1' and 'rs2' fields specify the source registers, in this case R2 and R1. The 'rd' field specifies the destination register, R3. When this 32-bit value is loaded into the Instruction Register, the control unit's decoders are just circuits wired to look at these specific bit fields. They activate the correct pathways in the ALU and register file to execute the command. This encoding scheme is the core of the ISA. It's the dictionary that translates between the programmer's intent and the hardware's capabilities.

• The control unit's decoders are just circuits wired to look
• The 'rs1' and 'rs2' fields specify the source registers
• The 'rd' field specifies the destination register, R3
• They activate the correct pathways in the ALU
• This encoding scheme is the core of the ISA

6. Moore's Law and Its Consequences

How shrinking transistors changed everything.

The relentless march of Moore's Law, the observation that the number of transistors on a chip doubles roughly every two years, has driven distinct generations of computer architecture. Each generation is defined by a few key properties. First is the underlying implementation technology. Early machines used vacuum tubes, then discrete transistors, then integrated circuits, and now Very Large-Scale Integration, or VLSI. This technology determines the raw potential for speed, cost, and power efficiency. Second is the ISA philosophy. Early architectures were often Complex Instruction Set Computers, or CISC, like the VAX or Intel's x86. They had powerful, multi-step instructions. In the 1980s, the RISC, or Reduced Instruction Set Computer, philosophy emerged, arguing for simpler instructions that could be executed faster, leaving complex operations to the compiler. ARM and RISC-V are modern examples. Third, the primary lever for performance has shifted. For decades, it was all about increasing clock speed. When we hit a 'power wall' in the mid-2000s, the focus shifted to parallelism—first at the instruction level, and now with multi-core processors. Finally, the architecture provides a stable abstraction layer, allowing software to survive across these massive hardware shifts.

• Driven by implementation technology (e.g., transistors, VLSI).
• Characterized by an ISA philosophy (e.g., CISC vs. RISC).
• Evolves performance levers (clock speed -> parallelism).
• Provides a stable abstraction layer for software.

7. Executing C = A + B

A step-by-step trace of a simple program.

Let's trace the execution of a tiny program to compute `C = A + B`. Assume the value of A, which is 5, is at memory address 100. The value of B, which is 10, is at address 101. We want to store the result C at address 102. Our program counter, PC, starts at 0. First, we fetch the instruction at address 0: `LOAD R1, 100`. The PC increments to 1. We decode and execute: the value from memory at address 100 is loaded into register R1. R1 now holds 5. Next, we fetch the instruction at PC=1: `LOAD R2, 101`. The PC increments to 2. We execute: the value from memory at address 101 is loaded into R2. R2 now holds 10. Next, fetch `ADD R3, R1, R2`. PC becomes 3. We execute: the ALU adds the contents of R1 and R2, and places the result, 15, into register R3. Finally, we fetch `STORE R3, 102`. PC becomes 4. We execute: the value in R3 is written to memory at address 102. Memory location 102 now holds 15. The program is complete. This mechanical, step-by-step process is all that's happening, just at an incredible speed.

• R1 now holds 5. Next
• We fetch STORE R3, 102. PC becomes 4. We execute
• R2 now holds 10. Next, fetch ADD R3, R1, R2
• PC becomes 3. We execute: the ALU adds the contents
• This mechanical, step-by-step process is all that's happening

8. Performance, Power, and Cost

There is no such thing as a free lunch, especially in hardware.

Computer architecture is fundamentally an art of managing tradeoffs. There is no universally 'best' processor, only a processor that is best for a given set of constraints. The most classic tradeoff is between performance, power, and cost. Want higher performance? You can add more execution units or increase the clock frequency, but both will increase power consumption and the physical size of the chip, which drives up cost. This is the 'power wall' that architects hit in the 2000s, ending the era of relentless clock speed increases. Another key tradeoff is generality versus specialization. A general-purpose CPU is a jack-of-all-trades, able to run any software. A specialized accelerator, like a GPU for graphics or a TPU for machine learning, is a master of one, offering orders of magnitude better performance and efficiency for its target workload, but it can do little else. Finally, there's the tension between backward compatibility and innovation. Maintaining compatibility with an old ISA, like x86, ensures existing software continues to run, but it can burden new designs with decades of legacy cruft. Every decision an architect makes is a negotiation between these competing forces.

• The 'power wall' that architects hit in the 2000s
• Maintaining compatibility with an old ISA
• There is no universally 'best' processor
• Computer architecture is fundamentally an art of managing tradeoffs
• The most classic tradeoff is between performance, power, and cost

9. The 'What' vs. The 'How'

Why your Intel and AMD chips can run the same code.

One of the most critical distinctions in this field is that between computer architecture and computer organization, also known as microarchitecture. Confusing the two is a common and fundamental error. Architecture is the 'what'. It is the abstract, functional definition of the system as seen by a programmer. It's the ISA: what instructions are available? How many registers are there? What are the memory addressing modes? It is the contract. Organization is the 'how'. It is the specific implementation of that architecture in hardware. How is the fetch-decode-execute cycle implemented? Is it pipelined? If so, how many stages? What is the size and structure of the cache? How does it predict branches? The analogy is a car's driver interface. The architecture is the steering wheel, pedals, and shifter. The organization is what’s under the hood: a V8 engine, a hybrid system, or an electric motor. Many different engines can implement the same driver interface. This is why both Intel and AMD can produce chips that run the same x86 software, despite their internal designs—their microarchitectures—being vastly different.

• Both Intel and AMD can produce chips that run the same
• One of the most critical distinctions in this field
• It is the abstract, functional definition of the system as seen
• The architecture is the steering wheel, pedals, and shifter
• The organization is what’s under the hood: a V8 engine

10. Four Traps for Newcomers

Mistakes that reveal a shallow understanding of the field.

As you delve into architecture, there are several common pitfalls to avoid. The first, as we just discussed, is conflating architecture with organization. Remember, the ISA is the interface, the organization is the implementation. Second is ignoring Amdahl's Law. This law provides a simple formula for the maximum speedup possible from an optimization. It reminds us that improving one small part of a system will have limited overall effect. If your program spends only 10% of its time doing floating-point math, even an infinitely fast floating-point unit can only make your program about 10% faster. Third is fixating on a single performance metric, like clock speed. In the 1990s, this was a reasonable proxy for performance. Today, it is nearly meaningless in isolation. Performance is a product of clock speed, instructions per cycle (IPC), core count, and memory system performance. Finally, and most subtly, is assuming the hardware/software abstraction is perfect. In reality, it leaks. Security vulnerabilities like Spectre demonstrated that details of the microarchitecture, like speculative execution, can have observable and dangerous effects on software, breaking the very contract the ISA is supposed to guarantee.

• Confusing architecture (the 'what') with organization (the 'how').
• Forgetting Amdahl's Law: optimizing the non-bottleneck.
• Fixating on a single metric like clock speed instead of holistic performance.
• Treating the hardware/software abstraction as a perfect, leak-proof barrier.

11. Simulators, Languages, and Foundational Texts

The instruments used to design the next generation of hardware.

How do architects design and evaluate new ideas? The first tool is simulation. Building a new processor is astronomically expensive, so ideas are tested first in software. Architectural simulators like gem5 or SimpleScalar are complex programs that model a processor's behavior and allow researchers to measure the performance impact of a new cache design or branch predictor. To actually describe the hardware for synthesis, we use Hardware Description Languages, or HDLs, like Verilog and VHDL. These languages are not for writing sequential programs; they describe parallel hardware structures. The foundational knowledge of the field is captured in two key textbooks, both by David Patterson and John Hennessy: 'Computer Organization and Design' for an undergraduate introduction, and 'Computer Architecture: A Quantitative Approach' for the graduate-level, in-depth treatment. Finally, the field moves forward through academic research published at premier conferences like ISCA, MICRO, and ASPLOS. Reading these papers is how you engage with the state-of-the-art.

• Building a new processor is astronomically expensive
• Architectural simulators like gem5 or SimpleScalar are complex programs that model
• The foundational knowledge of the field is captured in two key
• The field moves forward through academic research published at premier conferences
• These languages are not for writing sequential programs; they describe parallel

12. Programming a Fibonacci Sequence in RISC-V

Get your hands dirty with a real instruction set.

Theory is essential, but intuition is built through practice. This week's assignment is your first foray into programming directly at the ISA level. You will use an online simulator for the RISC-V instruction set. RISC-V is a modern, clean, and open-source ISA that is excellent for learning. Your task is to write a short assembly language program that computes the Nth Fibonacci number. The value N will be loaded from a fixed memory address, and you will store the result back into memory. The core of the assignment is not just to get the right answer, but to single-step through your program's execution in the simulator. For each instruction, you must observe and log the state of the machine: the program counter, and the contents of any registers that are read from or written to. The goal is to develop what we call 'mechanical sympathy'—a gut feeling for how the machine's state evolves, one simple instruction at a time. This is the most fundamental skill for an architect.

• RISC-V is a modern, clean
• This week's assignment is your first foray into programming directly
• You will use an online simulator for the RISC-V instruction
• The value N will be loaded from a fixed memory address
• The core of the assignment is not just to get

13. What We Learned Today

Today, we defined computer architecture as the critical interface between hardware and software, governed by the Instruction Set Architecture. We traced its history from mechanical calculators to the Von Neumann model that powers nearly all modern computing.

• Architecture is the programmer-visible interface (the ISA), not the specific implementation (the microarchitecture).
• The stored-program concept (Von Neumann architecture) was the key innovation enabling general-purpose computing.
• All modern processors operate on a fundamental Fetch-Decode-Execute cycle.
• Architectural design is a game of tradeoffs: performance, power, cost, and backward compatibility.
• Moore's Law's effects have shifted from clock speed to parallelism and specialization.

Mastery quiz

1. According to the class, what was the revolutionary 'stored-program concept' from von Neumann's 1945 First Draft on the EDVAC?
   • Programming by physically re-plugging cables and switches
   • Storing a program's instructions in memory alongside the data, so they can be read, written, and modified
   • Doubling the number of transistors on a chip every two years
   • Splitting complex instructions into simpler RISC instructions
2. In the trace of C = A + B (A=5 at address 100, B=10 at address 101), what value ends up stored at memory address 102?
   • 5
   • 10
   • 15
   • 102
3. The class contrasts architecture ('the what') with organization/microarchitecture ('the how'). Which is an organization question?
   • Which instructions are available in the ISA
   • How many registers the programmer can see
   • Whether the fetch-decode-execute cycle is pipelined and how many stages it has
   • What memory addressing modes the contract provides
4. Per the class's discussion of Amdahl's Law, if a program spends only 10% of its time on floating-point math, an infinitely fast floating-point unit can make the program at most about:
   • 10% faster
   • 2x faster
   • 90% faster
   • Infinitely faster