Lecture 1 Introduction and Basic

• "C" as a model of computation.
• Programmer's view of a computer system works.

---

• HardWare designer's view of a computer system works.

• Digital logic as a model of computation.

• How does an assembly program end up executing as digital logic?

---

• What happens in-between?
• How is a computer designed using logic gates and wires to satisfy specific goals?

---

• Architect/microarchitect's view:

How to design a computer that meets system design goals.

• Choices critically affect both the SW programmer and the HW designer.

How do we ensure problems are solved by electrons?

• program -> Algorithm -> Program/Language -> Runtime System(VM, OS, MM) -> ISA(Instruction Set Architecture) -> Microarchitecture -> Circuits -> Electrons

• ! ISA which is that interface between the hardware and software.

The Power of Abstraction

• Levels of transformation create abstractions

  • Abstraction: A higher level only needs to know about the interface to the lower level, not how the lower level is implemented.

  • E.g, High-level language programmer does not really need to know waht the ISA is and how a computer executes instructions.

• Abstraction improves productivity.

  • No need to worry about decisions made in underlying levvels.
  • E.g., programming in Java vs. C vs. assembly vs. binary vs. by specifying control signals of each transistor every cycle.

Crossing the Abstraction Layers

• As long as everything goes well, not knowing what happens in the underlying level (or above) is not a problem.

• What if

  • The program you wrote is running slow?
  • The program you wrote does not run correctyl?
  • The program you wrote consumes too much energy?

• What if

  • The hardware you designed is too hard to program?
  • The hardware you designed is too slow because it does not provide the right primitives to the software?

• One goal of this course is to understand how a processor works underneath the software layer and how decisions made in hardware affect the software/programmer

DRAM Controllers

• A row-conflict memory access takes significantly longer than a row-hit access

• Current controllers take advantage of the row buffer.

• Commonly used scheduling policy

  1. Row-hit first: Service row-hit memory accesses first
  2. Oldest-first: Then service older accesses first.

• This scheduling policy aims to maximize DRAM throughput.

The problem

• Multiple threads share the DRAM controller

• DRAM controllers designed to maxmize DRAM throughput

• DRAM scheduling policies are thread-unfair

  • Row-hit first: unfairly prioritizes threads with high row buffer locality
    • Threads that keep on accessing the same row.
  • Oldest-first: unfairly prioritizes memory-intensive threads

• DRAM controller vulnerable to denial of service attacks

  • Can write programs to exploit unfairness.

A Memory Performance Hog

STREAM

// initialize large aarrays A, B
for (j = 0; j < N; j++) {
    index = j * linesizze; // streaming
    A[index] = B[index];
    ...
}

• Sequential memory access
• Very high row buffer locality(96% hit rate)
• Memory intensive

RANDOM

// initialize large arrays A, B
for (j = 0, j < N; j++) {
    index = rand(); // random
    A[index] = B[index];
    ...
}

• Random memory access
• Very low row buffer locality (3% hit rate)
• Similarly memory intensive

Goals

• Teach/enable/empower you to:
  • Understand how a procesor works
  • Implement a simple processor (with not so simple parts)
  • Understand how decisions made in hardware affect the software/programmer as well as hardware designer
  • Think critically (in solving problems)
  • Think broadly across the levels of transformation
  • understand how to analyze and make tradeoffs in design.