CDA-4101 Lecture 2 Notes

Processors - CPU Organization, instruction, execution, RISC vs. CISC, design principles, paralellism Primary Memory - Bits, addresses, byte ordering, error-correcting codes, cache, memory packaging and types Secondary Memory - memory hierarchies, magnetic disks, floopy disks, IDE, SCSI, RAID, CD-ROM, CD-R, CD-RW, DVD Input/Output - buses, terminals, mice, printers, modems, character codes.

• CPU - the brain
• Bus - parallel wires for control signals, addresses and/or data.
  • External vs Internal
• I/O Devices
• Other processors - bus control, I/O device control
• CPU internals
  • Control Unit
  • Arithmetic Logic Unit (ALU)
  • Registers - general vs. special purpose
• Important Registers
  • Program Counter (PC)
  • Instruction Register (IR)

John von Neumann

• a.k.a., stored-program technique
• computational procedure not part of hardware (hardwired, or knobs and switches)
• simple, fixed structure capable of general purpose computing
• encode instructions as numbers (data)
• control unit fetches/decods and executes instructions
• instructions stored with data (data == program)
• programs can modify themselves
• single processing component
• sequential operation
• separation of storage from processing
• conditional control transfer

Registers ALU Dedicated A, B and Output registers not universal Instruction types register-memory register-register Data path cycle - the faster the better

1. Using program counter (PC) contents, fetch next instruction from memory into instruction register (IR)
2. Update PC to point to next instruction
3. Determine type of instruction (i.e., decode)
4. If requires data from memory, determine its address (e.g., decode, compute, fetch, etc.)
5. Put data from memory into register (if necessary)
6. Execute instruction
7. Write result back to register
8. Got to step 1

Level 0 is the hardware, whose "language" allows: moving data from memory to CPU feeding data through ALU other register manipulations Level 1 is the microarchitecture: Level 2 (ISA) instructions are interpreted by executing the fetch-decode-execute cycle fetch-decode-execute algorithm is the "microprogram" if done in software if done in hardware, it is intermingled with other hardware

• Fetch-Decode-Execute cycle just a program: could be hardware, could be software.
• A microprogram (i.e., Level 1 in software) allows the hardware to be simpler/cheaper, so all complexity lies in software.
• Complex instructions in hardware can be justified on the high-end, but factors (instruction compatibility, cost of software development on multiple platforms) forced complex instructions to the low-end
• IBM recognized the benefits of having a range of computers that were software compatible.
  IBM System/360:
  • high-end - hardware interpretation
  • low-end - software interpretation
• 70's was the decade of microprograms (read the textbook for more detailed description of the historical reasons, Section 2.1.2)

IBM 360

• Storing microprograms in fast read-only memories helped sustain the advantages of microprograms.
• Clarifying the book's example:

Microinstruction	Direct Execution	w/Control Store	w/o Control Store
1	0 ns	100 ns	500 ns
2	0 ns	100 ns	500 ns
3	0 ns	100 ns	500 ns
4	0 ns	100 ns	500 ns
(memory ref)	500 ns	500 ns	500 ns
5	0 ns	100 ns	500 ns
6	0 ns	100 ns	500 ns
(memory ref)	500 ns	500 ns	500 ns
7	0 ns	100 ns	500 ns
8	0 ns	100 ns	500 ns
9	0 ns	100 ns	500 ns
10	0 ns	100 ns	500 ns
Total	1,000 ns	2,000 ns	6,000 ns

> Too nice?

tailoring of the ISA instructions to match requirements of high-level languages and programmers. Instructions sets got bigger and more complex: microprogramming made this a feasible approach cost of memory at the time contributed to this trend as the programs themselves needed to be compact, so individual instructions doing more complex tasks would reduce program size. software was getting more expensive while processor technology was geting cheaper: thus a focus on moving complexity into the hardware. Also, compilers of the time were terrible: programmers were happy to get correct output, so size and efficiency of resulting code was not thought about.

Too silly?

Too sleepy?

the beginnings of a backlash: no Level 1 interpretation and simple ISA instruction sets. Thus was born two new acronyms: RISC = Reduced Instruction Set Computer (about 50) CISC = Complex Instruction Set Computer (200 to 300) The RISC instructions were not only simpler, but there tended to be fewer of them. RISC on the order of 50 instructions CISC on the order of 200 to 300 instructions (Note that this term did not exist until after the RISC ideas were introduced) VLSI (Very Large Scale Integration, Textbook Section 1.2) transitor densities helped RISC-based processors: CISC designs would be split among multiple chips which limited their performance.

Too strange?

• RISC had advantage of not requiring backwards compatibility, so could design instructions for speed.
• Speed of instruction execution was not as important as the speed of instruction initiation (exploiting parallelism).
• main memory speeds improved, decreasing usefulness of control stores.
• more amendable to pipeline (i.e., parallel) execution

• Essentially, processors, memory and compilers had advanced greatly in a short time bettwen the 70's and 80's, so many of the things that had caused the CISC machine to evolve the way they did no longer applied.
• RISC was more of a recognition of these facts than an entire new technology: i.e., a design philosophy change
• backward compatability requirement and existing software investment allowed CISC machines to continue to prosper.
• Since that time RISC machines have gotten more CISC-like and CISC machines have incorporated the best ideas of the RISC philosophy (e.g., Pentiums have a "RISC core").
• the driving force in processor development has been speed, not design philosophies.
• Today, the RISC vs. CISC polarization is more a marketing argument than a technology argument (similar to the "Domestic vs. Import" automotive argument.)

Common Instructions Executed by Hardware

• early RISC research showed that most of time was spent executing a small subset of instructions
• it is ok if less common instructions are interpreted and/or slower

Maximize Execution Issue Rate

• instruction latency not as important
• implies that instructions will have to complete at the same frequency as instructions are issued.
• implies parallel execution (how to do this will be discussed shortly)

Instructions Easy to Decode

• we will discuss the need for decoding and what it entails in future lectures
• for now, understand that there is a need to figure out what an instruction does and what data it needs, so the instruction's format should make doing this as easy as possible

Load/Store Architecture

• memory referencing instructions should be limited to load and store
• i.e., register-memory and memory-memory instructions are bad
• slow memory accesses can be done in parallel with other instructions

Many Registers

• early RISC research showed that most execution was spent accessing local variables
• frequent local variable references means memory access times can be minimized if there are enough registers to hold the most often used data