Instruction Set Architecture (ISA) Application •! What is a good ISA? OS •! Aspects of ISAs Compiler Firmware CIS 501 •! RISC vs. CISC Computer Architecture CPU I/O Memory Digital Circuits Unit 3: Instruction Set Architecture Gates & Transistors CIS 501 (Martin/Roth): Instruction Set Architectures 1 CIS 501 (Martin/Roth): Instruction Set Architectures 2 Readings •! H+P •! Appendix B •! Appendix J.2 (RISC ISAs) and J.3 (x86) •! On the Book’s CD •! Paper •! The Evolution of RISC Technology at IBM by John Cocke •! Much of this chapter will be “on your own reading” •! Hard to talk about ISA features without knowing what they do ISA Design Goals •! 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 What Is An ISA? A Language Analogy for ISAs •! ISA (instruction set architecture) •! Communication •! A well-defined hardware/software interface •! Person-to-person ! software-to-hardware •! The “contract” between software and hardware •! Similar structure •! Functional definition of operations, modes, and storage •! Narrative ! program locations supported by hardware •! Sentence ! insn •! Precise description of how to invoke, and access them •! Verb ! operation (add, multiply, load, branch) •! Not in the “contract”: non-functional aspects •! Noun ! data item (immediate, register value, memory value) •! How operations are implemented •! Adjective ! addressing mode •! Which operations are fast and which are slow and when •! Many different languages, many different ISAs •! Which operations take more power and which take less •! Similar basic structure, details differ (sometimes greatly) •! Key differences between languages and ISAs •! Instruction ! Insn •! Languages evolve organically, many ambiguities, inconsistencies •! ‘Instruction’ is too long to write in slides •! ISAs are explicitly engineered and extended, unambiguous CIS 501 (Martin/Roth): Instruction Set Architectures 5 CIS 501 (Martin/Roth): Instruction Set Architectures 6 RISC vs CISC Foreshadowing What Makes a Good ISA? •! Recall performance equation: •! Programmability •! (instructions/program) * (cycles/instruction) * (seconds/cycle) •! Easy to express programs efficiently? •! Implementability •! CISC (Complex Instruction Set Computing) •! Easy to design high-performance implementations? •! Reduce “instructions/program” with “complex” instructions •! More recently •! But tends to increase CPI or clock period •! Easy to design low-power implementations? •! Easy for assembly-level programmers, good code density •! Easy to design high-reliability implementations? •! RISC (Reduced Instruction Set Computing) •! Easy to design low-cost implementations? •! Improve “cycles/instruction” with many single-cycle instructions •! Compatibility •! Increases “instruction/program”, but hopefully not as much •! Easy to maintain programmability (implementability) as languages •! Help from smart compiler and programs (technology) evolves? •! Perhaps improve clock cycle time (seconds/cycle) •! x86 (IA32) generations: 8086, 286, 386, 486, Pentium, PentiumII, PentiumIII, Pentium4, Core2… •! via aggressive implementation allowed by simpler instructions CIS 501 (Martin/Roth): Instruction Set Architectures 7 CIS 501 (Martin/Roth): Instruction Set Architectures 8 Programmability Human Programmability •! Easy to express programs efficiently? •! What makes an ISA easy for a human to program in? •! For whom? •! Proximity to a high-level language (HLL) •! Closing the “semantic gap” •! Before 1985: human •! Semantically heavy (CISC-like) insns that capture complete idioms •! “Access array element”, “loop”, “procedure call” •! Compilers were terrible, most code was hand-assembled •! Example: SPARC save/restore •! Want high-level coarse-grain instructions •! Bad example: x86 (copy string) •! As similar to high-level language as possible rep movsb •! Ridiculous example: VAX insque (insert-into-queue) •! “Semantic clash”: what if you have many high-level languages? •! After 1985: compiler •! Optimizing compilers generate much better code that you or I •! Stranger than fiction •! Want low-level fine-grain instructions •! People once thought computers would execute language directly •! Compiler can’t tell if two high-level idioms match exactly or not •! Fortunately, never materialized (but keeps coming back around) CIS 501 (Martin/Roth): Instruction Set Architectures 9 CIS 501 (Martin/Roth): Instruction Set Architectures 10 Today’s Semantic Gap Compiler Programmability •! Today’s ISAs are actually targeted to one language… •! What makes an ISA easy for a compiler to program in? •! …Just so happens that this language is very low level •! Low level primitives from which solutions can be synthesized •! The C programming language •! Wulf: “primitives not solutions” •! Computers good at breaking complex structures to simple ones •! Will ISAs be different when Java/C# become dominant? •! Requires traversal •! Not so good at combining simple structures into complex ones •! Object-oriented? Probably not •! Requires search, pattern matching •! Support for garbage collection? Maybe •! Easier to synthesize complex insns than to compare them •! Support for bounds-checking? Maybe •! Why? •! Rules of thumb •! Smart compilers transform high-level languages to simple instructions •! Regularity: “principle of least astonishment” •! Any benefit of tailored ISA is likely small •! Orthogonality & composability •! One-vs.-all CIS 501 (Martin/Roth): Instruction Set Architectures 11 CIS 501 (Martin/Roth): Instruction Set Architectures 12 Aside: Compiler Optimizations Aside: Compiler Optimizations •! Compilers do two things •! Primarily reduce dynamic insn count •! Eliminate redundant computation, keep more things in registers + Registers are faster, fewer loads/stores •! Code generation ! –! An ISA can make this difficult by having too few registers •! Translate HLL to machine insns naively, one statement at a time •! Canonical, there are compiler-generating programs •! But also… •! Reduce branches and jumps •! Optimization •! Reduce cache misses •! Transform insns to preserve meaning but improve performance •! Reduce dependences between nearby insns (for parallelism) –! An ISA can make this difficult by having implicit dependences •! Active research area, but some standard optimizations •! Register allocation, common sub-expression elimination, •! How effective are these? loop-invariant code motion, loop unrolling, function inlining, +! Can give 4X performance over unoptimized code code scheduling (to increase insn-level parallelism), etc. –! Collective wisdom of 40 years (“Proebsting’s Law”): 4% per year •! Funny but … shouldn’t leave 4X performance on the table CIS 501 (Martin/Roth): Instruction Set Architectures 13 CIS 501 (Martin/Roth): Instruction Set Architectures 14 Implementability Compatibility •! Every ISA can be implemented •! No-one buys new hardware… if it requires new software •! Not every ISA can be implemented efficiently •! Intel was the first company to realize this •! ISA must remain compatible, no matter what •! Classic high-performance implementation techniques •! x86 one of the worst designed ISAs EVER, but survives •! Pipelining, parallel execution, out-of-order execution (more later) •! As does IBM’s 360/370 (the first “ISA family”) •! Backward compatibility •! Certain ISA features make these difficult •! New processors must support old programs (can’t drop features) –! Variable instruction lengths/formats: complicate decoding •! Critically important –! Implicit state: complicates dynamic scheduling •! Forward (upward) compatibility –! Variable latencies: complicates scheduling •! Old processors must support new programs (with software help) –! Difficult to interrupt instructions: complicate many things •! 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 15 CIS 501 (Martin/Roth): Instruction Set Architectures 16 The Compatibility Trap The Compatibility Trap Door •! Easy compatibility requires forethought •! Compatibility’s friends •! Temptation: use some ISA extension for 5% performance gain •! Trap: instruction makes low-level “function call” to OS handler •! Frequent outcome: gain diminishes, disappears, or turns to loss •! Nop: “no operation” - instructions with no functional semantics –! Must continue to support gadget for eternity •! Backward compatibility •! Handle rarely used but hard to implement “legacy” opcodes •! Example: register windows (SPARC) •! Define to trap in new implementation and emulate in software •! Adds difficulty to out-of-order implementations of SPARC •! Rid yourself of some ISA mistakes of the past •! Problem: performance suffers •! Forward compatibility •! Reserve sets of trap & nop opcodes (don’t define uses) •! Add ISA functionality by overloading traps •! Release firmware patch to “add” to old implementation •! Add ISA hints by overloading nops (example: x86’s PAUSE) CIS 501 (Martin/Roth): Instruction Set Architectures 17 CIS 501 (Martin/Roth): Instruction Set Architectures 18 Aspects of ISAs •! VonNeumann model •! Implicit structure of all modern ISAs •! Format •! Length and encoding •! Operand model •! Where (other than memory) are operands stored? •! Datatypes and operations •! Control Aspects of ISAs •! Overview only •! Read about the rest in the book and appendices CIS 501