Instruction Set Architecture (ISA) Application • What is a good ISA? OS • Aspects of ISAs Compiler Firmware CIS 501 • RISC vs. CISC Introduction to Computer Architecture CPU I/O • Implementing CISC: µISA Memory Digital Circuits Unit 2: Instruction Set Architecture Gates & Transistors CIS 501 (Martin/Roth): Instruction Set Architectures 1 CIS 501 (Martin/Roth): Instruction Set Architectures 2 Readings What Is An ISA? • H+P • ISA (instruction set architecture) • Chapter 2 • A well-define hardware/software interface • Further reading: • Appendix C (RISC) and Appendix D (x86) • The “contract” between software and hardware • Functional definition of operations, modes, and storage • Available from web page locations supported by hardware • Precise description of how to invoke, and access them • Paper • The Evolution of RISC Technology at IBM by John Cocke • No guarantees regarding • How operations are implemented • Much of this chapter will be “on your own reading” • Which operations are fast and which are slow and when • Which operations take more power and which take less • Hard to talk about ISA features without knowing what they do • We will revisit many of these issues in context CIS 501 (Martin/Roth): Instruction Set Architectures 3 CIS 501 (Martin/Roth): Instruction Set Architectures 4 A Language Analogy for ISAs RISC vs CISC Foreshadowing • A ISA is analogous to a human language • Recall performance equation: • Allows communication • (instructions/program) * (cycles/instruction) * (seconds/cycle) • Language: person to person • ISA: hardware to software • CISC (Complex Instruction Set Computing) • Need to speak the same language/ISA • Improve “instructions/program” with “complex” instructions • Many common aspects • Easy for assembly-level programmers, good code density • Part of speech: verbs, nouns, adjectives, adverbs, etc. • Common operations: calculation, control/branch, memory • RISC (Reduced Instruction Set Computing) • Many different languages/ISAs, many similarities, many differences • Improve “cycles/instruction” with many single-cycle instructions • Different structure • Increases “instruction/program”, but hopefully not as much • Both evolve over time • Help from smart compiler • Key differences: ISAs must be unambiguous • Perhaps improve clock cycle time (seconds/cycle) • ISAs are explicitly engineered and extended • via aggressive implementation allowed by simpler instructions CIS 501 (Martin/Roth): Instruction Set Architectures 5 CIS 501 (Martin/Roth): Instruction Set Architectures 6 What Makes a Good ISA? Programmability • Programmability • Easy to express programs efficiently? • Easy to express programs efficiently? • For whom? • Implementability • Easy to design high-performance implementations? • Before 1985: human • More recently • Compilers were terrible, most code was hand-assembled • Easy to design low-power implementations? • Want high-level coarse-grain instructions • Easy to design high-reliability implementations? • As similar to high-level language as possible • Easy to design low-cost implementations? • Compatibility • After 1985: compiler • Easy to maintain programmability (implementability) as languages • Optimizing compilers generate much better code that you or I and programs (technology) evolves? • Want low-level fine-grain instructions • x86 (IA32) generations: 8086, 286, 386, 486, Pentium, PentiumII, PentiumIII, Pentium4,… • Compiler can’t tell if two high-level idioms match exactly or not CIS 501 (Martin/Roth): Instruction Set Architectures 7 CIS 501 (Martin/Roth): Instruction Set Architectures 8 Human Programmability Compiler Programmability • What makes an ISA easy for a human to program in? • What makes an ISA easy for a compiler to program in? • Proximity to a high-level language (HLL) • Low level primitives from which solutions can be synthesized • Closing the “semantic gap” • Wulf: “primitives not solutions” • Semantically heavy (CISC-like) insns that capture complete idioms • Computers good at breaking complex structures to simple ones • “Access array element”, “loop”, “procedure call” • Requires traversal • Example: SPARC save/restore • Not so good at combining simple structures into complex ones • Bad example: x86 rep movsb (copy string) • Requires search, pattern matching (why AI is hard) • Ridiculous example: VAX insque (insert-into-queue) • Easier to synthesize complex insns than to compare them • “Semantic clash”: what if you have many high-level languages? • Rules of thumb • Stranger than fiction • Regularity: “principle of least astonishment” • People once thought computers would execute language directly • Orthogonality & composability • Fortunately, never materialized (but keeps coming back around) • One-vs.-all CIS 501 (Martin/Roth): Instruction Set Architectures 9 CIS 501 (Martin/Roth): Instruction Set Architectures 10 Today’s Semantic Gap Implementability • Popular argument • Every ISA can be implemented • Today’s ISAs are targeted to one language… • Not every ISA can be implemented efficiently • Just so happens that this language is very low level • The C programming language • Classic high-performance implementation techniques • Pipelining, parallel execution, out-of-order execution (more later) • Will ISAs be different when Java/C# become dominant? • Object-oriented? Probably not • Certain ISA features make these difficult • Support for garbage collection? Maybe – Variable instruction lengths/formats: complicate decoding • Support for bounds-checking? Maybe – Implicit state: complicates dynamic scheduling • Why? – Variable latencies: complicates scheduling • Smart compilers transform high-level languages to simple – Difficult to interrupt instructions: complicate many things instructions • Any benefit of tailored ISA is likely small CIS 501 (Martin/Roth): Instruction Set Architectures 11 CIS 501 (Martin/Roth): Instruction Set Architectures 12 Compatibility The Compatibility Trap • No-one buys new hardware… if it requires new software • Easy compatibility requires forethought • Intel was the first company to realize this • Temptation: use some ISA extension for 5% performance gain • ISA must remain compatible, no matter what • Frequent outcome: gain diminishes, disappears, or turns to loss • x86 one of the worst designed ISAs EVER, but survives – Must continue to support gadget for eternity • As does IBM’s 360/370 (the first “ISA family”) • Backward compatibility • Example: register windows (SPARC) • New processors must support old programs (can’t drop features) • Adds difficulty to out-of-order implementations of SPARC • Very important • Details shortly • Forward (upward) compatibility • Old processors must support new programs (with software help) • New processors redefine only previously-illegal opcodes • Allow software to detect support for specific new instructions • Old processors emulate new instructions in low-level software CIS 501 (Martin/Roth): Instruction Set Architectures 13 CIS 501 (Martin/Roth): Instruction Set Architectures 14 The Compatibility Trap Door Aspects of ISAs • Compatibility’s friends • VonNeumann model • Trap: instruction makes low-level “function call” to OS handler • Implicit structure of all modern ISAs • Nop: “no operation” - instructions with no functional semantics • Format • Backward compatibility • Length and encoding • Handle rarely used but hard to implement “legacy” opcodes • Operand model • Define to trap in new implementation and emulate in software • Where (other than memory) are operands stored? • Rid yourself of some ISA mistakes of the past • Datatypes and operations • Problem: performance suffers • Control • Forward compatibility • Reserve sets of trap & nop opcodes (don’t define uses) • Add ISA functionality by overloading traps • Overview only • Release firmware patch to “add” to old implementation • Read about the rest in the book and appendices • Add ISA hints by overloading nops CIS 501 (Martin/Roth): Instruction Set Architectures 15 CIS 501 (Martin/Roth): Instruction Set Architectures 16 The Sequential Model Format • Implicit model of all modern ISAs • Length • Often called VonNeuman, but in ENIAC before • Fixed length Fetch PC • Basic feature: the program counter (PC) • Most common is 32 bits Decode • Defines total order on dynamic instruction + Simple implementation: compute next PC using only PC Read Inputs • Next PC is PC++ unless insn says otherwise – Code density: 32 bits to increment a register by 1? Execute • Order and named storage define computation – x86 can do this in one 8-bit instruction • Value flows from insn X to Y via storage A iff… Write Output • Variable length • X names A as output, Y names A as input… Next PC – Complex implementation • And Y after X in total order + Code density • Processor logically executes loop at left • Compromise: two lengths • Instruction execution assumed atomic • MIPS16 or ARM’s Thumb • Instruction X finishes before insn X+1 starts • Encoding • Alternatives have been proposed… • A few simple encodings simplify decoder implementation CIS 501 (Martin/Roth): Instruction Set Architectures 17 CIS 501 (Martin/Roth): Instruction Set Architectures 18 Example: MIPS Format Operand Model: Memory Only • Length • Where (other than memory) can operands come from? • 32-bits • And how are they specified? • Example: A = B + C • Encoding • Several options • 3 formats, simple encoding • Q: how many instructions can be encoded? A: 127 • Memory only add B,C,A mem[A] = mem[B] + mem[C] R-type Op(6) Rs(5) Rt(5) Rd(5) Sh(5) Func(6) I-type Op(6) Rs(5) Rt(5) Immed(16) J-type Op(6) Target(26)