Outline What Makes a Good ISA? Programmability Implementability

Outline What Makes a Good ISA? Programmability Implementability

Outline What Makes a Good ISA? • Instruction Sets in General • Programmability • MIPS Assembly Programming • Easy to express programs efficiently? • Other Instruction Sets • Implementability • Goals of ISA Design • Easy to design high-performance implementations (i.e., microarchitectures)? • RISC vs. CISC • Intel x86 (IA-32) • Compatibility • Easy to maintain programmability as languages and programs evolve? • Easy to maintain implementability as technology evolves? © 2012 Daniel J. Sorin 66 © 2012 Daniel J. Sorin 67 from Roth and Lebeck from Roth and Lebeck Programmability Implementability • Easy to express programs efficiently? • Every ISA can be implemented • For whom? • But not every ISA can be implemented well • Human • Bad ISA bad microarchitecture (slow, power-hungry, etc.) • Want high-level coarse-grain instructions • As similar to HLL as possible • We’d like to use some of these high-performance • This is the way ISAs were pre-1985 implementation techniques • Compilers were terrible, most code was hand-assembled • Pipelining, parallel execution, out-of-order execution • Compiler • We’ll discuss these later in the semester • Want low-level fine-grain instructions • Compiler can’t tell if two high-level idioms match exactly or not • Certain ISA features make these difficult • This is the way most post-1985 ISAs are • Variable length instructions • Optimizing compilers generate much better code than humans • Implicit state (e.g., condition codes) • ICQ: Why are compilers better than humans? • Wide variety of instruction formats © 2012 Daniel J. Sorin 68 © 2012 Daniel J. Sorin 69 from Roth and Lebeck from Roth and Lebeck Compatibility Compatibility in the Age of VMs • Few people buy new hardware … if it means they have to • Virtual machine (VM) : piece of software that emulates buy new software, too behavior of hardware platform • Intel was the first company to realize this • Examples: VMWare, Xen, Simics • ISA must stay stable, no matter what (microarch. can change) • VM emulates target system while running on host system • x86 is one of the ugliest ISAs EVER, but survives • Key: host and target ISAs do not have to be the same! • Intel then forgot this lesson: IA-64 (Itanium) is new ISA • Example: On my x86 desktop, I can run VM that emulates MIPS • Backward compatibility : very important processor • New processors must support old programs (can’t drop features) • ICQ: Is SPIM a VM? • Forward (upward) compatibility : less important • Upshot: you can run code of target ISA on host with different ISA don’t need to buy x86 box to run legacy x86 code • Old processors must support new programs • Very cool technology that’s commonly used • New processors only re-define opcodes that trapped in old ones • Old processors emulate new instructions in low-level software • ICQ: given a VM, does ISA compatibility really matter? • More details on VMs in ECE 252 © 2012 Daniel J. Sorin 70 © 2012 Daniel J. Sorin 71 from Roth and Lebeck from Roth and Lebeck RISC vs. CISC The Setup • RISC : reduced-instruction set computer • Pre-1980 • Coined by P+H in early 80’s (ideas originated earlier) • Bad compilers • CISC : complex-instruction set computer • Complex, high-level ISAs • Not coined by anyone, term didn’t exist before “RISC” • Slow, complicated, multi-chip microarchitectures • Around 1982 • Religious war (one of several) started in mid 1980’s • Advances in VLSI made single-chip microprocessor possible… • RISC (MIPS, Alpha, Power) “won” the technology battles • Speed by integration, on-chip wires much faster than off-chip • CISC (IA32 = x86) “won” the commercial war • …but only for very small, very simple ISAs • Compatibility a stronger force than anyone (but Intel) thought • Compilers had to get involved in a big way • Intel beat RISC at its own game … more on this soon • RISC manifesto : create ISAs that… • Simplify single-chip implementation • Facilitate optimizing compilation © 2012 Daniel J. Sorin 72 © 2012 Daniel J. Sorin 73 from Roth and Lebeck from Roth and Lebeck The RISC Tenets PowerPC ISA POWER ISA • Single-cycle execution (simple operations) • RISC-y, very similar to MIPS • CISC: many multi-cycle operations • Some differences: • Load/store architecture • Indexed addressing mode (register+register) • CISC: register-memory and memory-memory instructions • lw $t1,$a0,$s3 # $t1 = mem[$a0+$s3] • Few memory addressing modes • Update addressing mode • CISC: many modes • lw $t1,4($a0) # $t1 = mem[$a0+4]; $a0 += 4; • Fixed instruction format • Dedicated counter register • bc loop # ctr--; branch to loop if ctr != 0 • CISC: many formats and lengths • In general, though, similar to MIPS • Reliance on compiler optimizations • CISC: hand assemble to get good performance Summary (1) Make it easy to implement in hardware (2) Make it easy for compiler to generate code © 2012 Daniel J. Sorin 74 © 2012 Daniel J. Sorin 75 from Roth and Lebeck from Roth and Lebeck Intel 80x86 ISA (aka x86 or IA-32) Intel x86: The Penultimate CISC • Binary compatibility across generations • DEC VAX was ultimate CISC, but x86 (IA-32) is close • 1978: 8086, 16-bit, registers have dedicated uses • Variable length instructions: 1-16 bytes • 1980: 8087, added floating point (stack) • Few registers: 8 and each one has a special purpose • 1982: 80286, 24-bit • Multiple register sizes: 8,16,32 bit (for backward compatibility) • 1985: 80386, 32-bit, new instrs GPR almost • Accumulators for integer instrs, and stack for FP instrs • 1989-95: 80486, Pentium, Pentium II • Multiple addressing modes: indirect, scaled, displacement • Register-register, memory-register, and memory-register insns • 1997: Added MMX instructions (for graphics) • Condition codes • 1999: Pentium III • Instructions for memory stack management (push, pop) • 2002: Pentium 4 • Instructions for manipulating strings (entire loop in one instruction) • 2004: “Nocona” 64-bit extension (to keep up with AMD) • Summary: yuck! • 2006: Core2 • 2007: Core2 Quad © 2012 Daniel J. Sorin 76 © 2012 Daniel J. Sorin 77 from Roth and Lebeck from Roth and Lebeck 80x86 Registers and Addressing Modes 80x86 Addressing Modes • Eight 32-bit registers (not truly general purpose) • Register Indirect • EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI • mem[reg] • Six 16-bit registers for code, stack, & data • not ESP or EBP register • Base + displacement (8 or 32 bit) • 2-address ISA • mem[reg + const] • One operand is both source and destination • not ESP or EBP • NOT a Load/Store ISA • Base + scaled index • One operand can be in memory • mem[reg + (2 scale x index)] • scale = 0,1,2,3 • base any GPR, index not ESP • Base + scaled index + displacement • mem[reg + (2 scale x index) + displacement] • scale = 0,1,2,3 • base any GPR, index not ESP © 2012 Daniel J. Sorin 78 © 2012 Daniel J. Sorin 79 from Roth and Lebeck from Roth and Lebeck Condition Codes 80x86 Instruction Encoding • Both Power ISA and x86 ISA have condition codes • Variable size 1-byte to 17-bytes • Special HW register that has values set as side effect of • Examples instruction execution • Jump (JE) 2-bytes • Example conditions • Push 1-byte • Zero • Add Immediate 5-bytes • Negative • W bit says 32-bits or 8-bits • Example use • D bit indicates direction subi $t0, $t0, 1 • memory reg or reg memory bz loop // branch to loop if result of previous instruction is zero • movw EBX, [EDI + 45] • movw [EDI + 45], EBX © 2012 Daniel J. Sorin 80 © 2012 Daniel J. Sorin 81 from Roth and Lebeck from Roth and Lebeck Decoding x86 Instructions How Intel Won Anyway • Is a &$%!# nightmare! • x86 won because it was the first 16-bit chip by 2 years • Instruction length is variable from 1 to 17 bytes • IBM put it into its PCs because there was no competing choice • Crazy “formats” register specifiers move around • Rest is historical inertia and “financial feedback” • x86 is most difficult ISA to implement and do it fast but… • But key instructions not terrible • Because Intel (and AMD) sells the most processors… • Yet, everything must work correctly • It has the most money… • Which it uses to hire more and better engineers… • Which it uses to maintain competitive performance … • And given equal performance compatibility wins… • So Intel (and AMD) sells the most processors… • Moore’s law has helped Intel in a big way • Most engineering problems can be solved with more transistors © 2012 Daniel J. Sorin 82 © 2012 Daniel J. Sorin 83 from Roth and Lebeck from Roth and Lebeck Current Approach: Pentium Pro and beyond Aside: Complex Instructions • Instruction decode logic translates into µops • More powerful instructions not necessarily faster • Fixed-size instructions moving down execution path execution • Execution units see only µops • E.g., string copy or polynomial evaluation + Faster instruction processing with backward compatibility + Execution unit as fast as RISC machines like MIPS • Option 1: use “repeat” prefix on memory-memory move inst – Complex decoding • Custom string copy – We work with MIPS to keep decoding simple/clean • Option 2: use a loop of loads and stores through registers • General purpose move through simple instructions – Learn x86 on the job! • Option 2 is often faster on same machine Learn exactly how this all works in ECE 252 © 2012 Daniel J. Sorin 84 © 2012 Daniel J. Sorin 85 from Roth and Lebeck from Roth and Lebeck Concluding Remarks Outline 1. Keep it simple and regular • Instruction Sets in General • Uniform length instructions • MIPS Assembly Programming • Fields always in same places • Other Instruction Sets 2. Keep it simple and fast • Small number of registers 3. Make sure design can be pipelined (will learn soon) 4. Make the common case fast • Compromises inevitable there is no perfect ISA © 2012 Daniel J. Sorin 86 © 2012 Daniel J. Sorin 87 from Roth and Lebeck from Roth and Lebeck .

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    6 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us