1. ARQUITECTURA DE COMPUTADORESUn enfoque cuantitativo

2. CONSULTORESEDITORIALESAREA DE INFORMATICA Y COMPUTACIONAntonio Vaquero SnchezCatedrtico de InformticaFacultad de Ciencias FsicasUniversidad Complutense de MadridESPANAGerardo Quiroz VieyraIngeniero en Comunicaciones y ElectrnicaEscuela Superior de Ingeniena Mecnica y Elctrica IPNCarter Wallace, S. A.Universidad Autnoma MetropolitanaDocente DCSAMEXICO 3. ARQUITECTURA DE COMPUTADORESUn enfoque cuantitativoJohn L. HennessyUniversidadde StanfordDavid A. PattersonUniversidadde California en BerkeleyTraduccinJUAN MANUEL SANCHEZUniversidad Complutense de MadridRevisin tcnicaANTONIO GONZALEZMATE0 VALER0Universidad Politcnica de CataluaANTONIO VAQUEROUniversidad Complutense de MadridMADRID BUENOS AIRES m CARACAS GUATEMALA LISBOA MEXICONUEVA YORK PANAMA SAN JUAN SANTAFE DE BOGOTA SANTIAGO SAO PAULOAUCKLAND HAMBURGO LONDRES MlLAN MONTREAL NUEVA DELHl PAR6SAN FRANCISCO SIDNEY SINGAPUR ST. LOUlS TOKIO TORONTO 4. ARQUITECTURADE COMPUTADORES.UN ENFOQUECUANTITATIVONo est permitida la reproduccin total o parcial de este libro, ni su tratamiento in-formtico,ni la transmisin de ninguna forma o por cualquier medio, ya sea electr-nico, mecnico, por fotocopia,por registro u otros mtodos, sin el permiso previo ypor escritode los titulares del Copyright.DERECHOS RESERVADOS O 1993 respecto a la primera edicin en espaol porMcGRAW-HILLPNTERAMERICANA DE ESPANA,S. A. U.Edificio Valrealty, la. plantaBasauri, 1728023 Aravaca (Madrid)Traducido de la primera edicin en inglsdeCOMPUTER ARCHITECTURE. A QUANTITATIVE APPROACHCopyright O MLMXC, por Morgan Kaufmann Publishers,Inc.ISBN: 1-55860-069-8ISBN: 84-7615-912-9Depsito legal: M. 41.104-2002Editor: Mariano J. NorteCubierta: F. Piuela. Grafismo electrnicoCompuesto en: FER Fotocomposicin,S. A.Impreso en: LAVEL, Industria Grfica, S. A.PRINTED IN SPAIN - IMPRESO EN ESPANA 5. A Andrea, Linda y nuestros cuatro hijos 6. Marcas registradasLas siguientesmarcas registradas son propiedad de las siguientes organizaciones:Alliant es una marca registrada de Alliant Computers.AMD 29000 es una marca registrada de AMD.TeX es una marca registrada de American Mathematical Society.AMI 6502 es una marca registradade AMI.Apple 1, Apple 11y Macintosh son marcas registradas de Apple Compu-ter, Inc.ZS-l es una marca registrada de Astronautics.UNIX y UNIX F77 son marcas registradas de AT&T Bell Laboratories.Turbo C es una marca registrada de Borland International.The Cosmic Cube es una marca registrada de California Institutc ofTechnology.Warp, C.mmp y Cm* son marcas registradas de Carnegie-Mellon lJni-versity.CP3100 es una marca registrada de Conner Peripherals.CDC 6600, CDC 7600, CDC STAR-100,CYBER- 180,CYBER 1801990y CYBER-205 son marcas registradas de Control Data Corporation.Convex, C-1, C-2 y C series son marcas registradas de Convex.CRAY-3 es una marca registrada de Cray Computer Corporation.CRAY-1, CRAY-IS, CRAY-2, CRAY X-MP, CRAY X-MP1416,CRAYY-MP, Cm77 V3.0, CFT y CFT2 V1.3a son marcas registradas de CrayResearch.Cydra 5 es una marca registrada de Cydrome.CY7C601,7C601,7C604 y 7C157 son marcas registradas de Cypress Se-miconductor.Nova es una marca registrada de Data General Corporation.HEP es una marca registrada de Denelcor.CVAX, DEC, DECsystem, DECstation, DECstation 3100, DECsystem10120, fort, LPI 1, Massbus, MicroVAX-1, MicroVAX-11, PDP-8, PDP-10, PDP-I 1, RS-I IMIIAS, Unibus, Ultrix, Ultrix 3.0, VAX, VAXsta-tion, VAXstation 2000, VAXstation 3100, VAX-I 1, VAX-111780, VAX-111785,VAX Model730, Model750, Model780, VAX 8600, VAX 8700,VAX 8800, VS FORTRAN V2.4 y VMS son marcas registradas de Di-gital Equipment Corporation.BlNAC es una marca registrada de Eckert-Mauchly Computer Corpora-tion.Multimax es una marca registrada de Encore Computers.ETA 10es una marca registrada de ETA Corporation.SYMBOL es una marca registrada de Fairchild Corporation.Pegasus es una marca registrada de Ferranti, Ltd.Ferran y Testarossa son marcas registradas de Ferrari Moton.AP-I2OB es una marca registrada de Floating Point Systems.Ford y Escort son marcas registradas de Ford Motor Co.Gnu C Compiler es una marca registrada de Free Software Foundation.M2361A, Super Eagle, VPlOO y VP200 son marcas registradasde FujitsuCorporation.Chevrolet y Corvette son marcas registradas de General Motors Corpo-ration.HP Precision Architecture, HP 850, HP 3000, HP 3000170, Apollo DN300, Apollo DN 10000 y Precision son marcas registradas de Hewlett-Packard Company.S810, S8101200y S820 son marcas registradas de Hitachi Corporation.Hyundai y Excel son marcas registradas de Hyundai Corporation.432,960 CA, 4004,8008,8080,8086,8087,8088,80186,80286,80386,80486, iAPX 432, i860, Intel, Multibus, Multibus 11 e Intel Hypercubeson marcas registradas de lntel Corporation.lnmos y Transputer son marcas registradas de Inmos.Clipper ClOO es una marca registrada de Intergraph.ESAl370, System/360, Systeml370, 701, 704, 709, 801, 3033, 3080. 3080series, 3080 VF, 3081, 3090, 30901100, 3090/200, 30901400, 30901600,30901600S. 3090 VF. 3330. 3380. 3380D. 3380 Disk Model AK4, 33803.3390, 3880-23, 3990,7030,7090,7094, IBM FORTRAN, ISAM, MVS,IBM PC, IBM PC-AT, PL.8, RT-PC, SAGE, Stretch, IBM SVS, VectorFacility y VM son marcas registradas de International Business MachinesCorporation.FutureBus es una marca registrada de Institute of Electrical and Electro-nic Engineen.Lamborghini y Countach son marcas registradas de Nuova AutomobiliFemcio Lamborghini, SPA.Lotus 1-2-3es una marca registrada de Lotus Development Corporation.MB8909 es una marca registrada de LSI Logic.NuBus es una marca registrada de Massachusetts Institute of Techno-~WY.Miata y Mazda son marcas registradas de Mazda.MASM, Microsoft Macro Assembler, MS DOS, MS DOS 3.1 y OS12 sonmarcas registradas de Microsoft Corporation.MIPS, MIPS 120, MIPS/I2OA, M/500. M/1000, RC6230, RC6280,R2000, R2000A, R2010, R3000 y R3010 son marcas registradasde MIPSComputer Systems.Delta Senes 8608, System VI88 R32V1, VME bus, 6809, 68000, 68010,68020,68030,68882,88000,88000 1.8.4m14, 88100 y 88200 son mar-cas registradas de Motorola Corporation.Multiflow es una marca registrada de Multiflow Corporation.National 32032 y 32x32 son marcas registradas de National Semicon-ductor Corporation.Ncube es una marca registrada de Ncube Corporation.SX/2, SX/3 y FORTRAN 77/SX V.040 son marcas registradas de NECInformation Systems.NYU Ultracomputer es una marca registrada de New York University.VAST-2 v.2.21 es una marca registrada de Pacific Sierra.Wren IV, Imprimis, Sabre 97209 e IPI-2 son marcas registradas de Sea-gate Corporation.Sequent, Balance 800, Balance 21000 y Symmetry son marcas registra-das de Sequent Computers.Silicon Graphics 4Dl60, 4D1240 y Silicon Graphics 4D Series son mar-cas registradas de Silicon Graphics.Stellar GS 1000, Stardent-1500 y Ardent Titan-I son marcas registradasde Stardent.Sun 2, Sun 3, Sun 3/75, Sun 31260, Sun 31280, Sun 4, Sun 41110, Sun41260, Sun 41280, SunOS 4.0.3c, Sun 1.2 FORTRAN compiler, SPARCy SPARCstation I son marcas registradas de Sun Microsystems.Synapse N+ es una marca registrada de Synapse.Tandem y Cyclone son marcas registradas de Tandem Computers.TI 8847 y TI ASC son marcas registradas de Texas Instmments Corpo-ration.Connection Machine y CM-2 son marcas registradas de Tbinking Ma-chines.Burroughs 6500, B5000, B5500, D-machine, UNIVAC, UNIVAC 1 yUNIVAC 1103 son marcas registradas de UNISYS.Spice y 4.2 BSD UNIX son marcas registradas de Univenity of Califor-nia, Berkeley.Illiac, Illiac IV y Cedar son marcas registradas de University of Illinois.Ada es una marca registrada de U.S. Government (Ada Joint ProgramOffice).Weitek 3364, Weitek 1 167,WTL 3110y WTL 3170 son marcas registra-das de Weitek Computen.Alto, Ethemet, PARC, Palo Alto Research Center, Smalltalk y Xerox sonmarcas registradas de Xerox Corporation.2-80 es una marca registrada de Zilog. 7. Prefaciopor C. Gordon Be11Estoy encantado y satisfechode escribir el prefacio de este libro decisivo.Los autores han ido ms all de las contribuciones de Thomas al Clculoy de Samuelson a la Economa. Han proporcionado el texto y referencia de-finitivos para el diseoy arquitectura de computadores. Para avanzar en com-putacin, recomiendo encarecidamente a los editores que retiren los monto-nes de libros sobre este tpico de manera que, rpidamente, pueda emergeruna nueva raza de arquitecto/ingeniero. Este libro no eliminar los micropro-cesadorescomplejos y llenos de errores de las compaas de semicomputado-res, pero acelerar la educacin de ingenieros que podrn disearlos mejor.El libro presenta las herramientas crticas para analizar los computadoresuniprocesadores. Muestra al ingeniero en ejerciciocmo cambia la tecnologaa lo largo del tiempo y ofrece las constantes empricas que se necesitan parael diseo. Motiva al diseador sobre la funcin, que es una orientacin msagradable que la habitual lista exhaustiva de los mecanismos que un disea-dor novel ~ u e d eintentar incluir en un nico diseo.Los autores establecen un punto de partida para realizar anlisis y com-paraciones utilizando la mquina ms importante de cada clase: computado-res grandes (IBM 360), mini (DEC VAX), y micro PC (Intel 80x86). Con estabase, muestran la lnea futura de procesadores paralelos segmentados mssimples. Estas nuevas tecnologas se muestran como variantes de su procesa-dor (DLX) til pedaggicamente, pero altamente realizable. Los autores ha-cen nfasis en la independencia de la tecnologa al medir el trabajo realizadopor ciclo de reloj (paralelismo), y el tiempo para hacer el trabajo (eficiencia ylatencia). Estos mtodos tambin mejorarn la calidad de la investigacin so-bre nuevas arquitecturas y paralelismo.Por ello, el libro es necesario que lo conozca cualquiera que trabaje en ar-quitectura o hardware, incluyendo arquitectos, ingenieros de sistemas decomputadores y de circuitos integrados, e ingenieros de sistemas operativos ycompiladores. Es til especialmente para los ingenieros de software que escri-ben programas para computadores vectoriales y segmentados. Los empresa-rios y vendedores se beneficiarn al conocer las seccionesde Falacias y Pifiasdel libro. El fracaso de muchos computadores -y ocasionalmente, de algunacompaa- se puede atribuir a ingenieros que fallan al comprender las suti-lezas del diseo de com~utadores.Los dos primeros captulos establecen la esencia del diseo de computa-dores a travs de medidas y de la comprensin de la relacin preciolrendi- 8. PREFACIOmiento. Estos conceptos se aplican a la arquitectura a nivel de lenguaje m-quina y a la forma de medirla. Explican la implementacin de procesadores eincluyen amplias discusiones sobre tcnicas para disear procesadores vecto-riales y segmentados. Tambin hay captulos dedicadosa la jerarqua de me-moria y a las, con frecuencia, despreciadas entradas/salidas. El captulo finalpresenta oportunidades y preguntas sobre mquinas y directrices futuras.Ahora, necesitamos su siguiente libro sobre cmo construir estas mquinas.La razn por la que este libro constituye un estndar sobre todos los an-teriores y es improbable que sea sustituido en un futuro previsible es la com-prensin, experiencia, gusto y unicidad de los autores. Han estimulado elcambio principal en arquitectura por su trabajo sobre los RISC (Pattersonacu la palabra). Su investigacin universitaria que llev al desarrollo deproductos en MIPS y Sun Microsystems;estableci importantes arquitecturaspara los aos 90. As, han hecho anlisis, evaluado compromisos, trabajadosobre compiladoresy sistemas operativos, y visto que sus mquinas consiguenimportancia con el uso. Adems, como maestros, han visto que el libro es pe-daggicamente slido (y han solicitado opiniones de los dems a travs delprograma de examen sin precedentesBeta). Estoy convencidoque ste ser ellibro de la dcada en sistemas de computadores. Quizs su mayor logro seaestimular a otros grandes arquitectos y diseadores de sistemas de alto nivel(bases de datos, sistemas de comunicaciones,lenguajes y sistemas operativos)a escribir libros similares sobre sus dominios.Yo ya he aprendido y me he divertido con el libro, y usted, seguramente,tambin.C. Gordon Be11 9. 1 ContenidoPrefaciopor G. GORDON BELLAgradecimientosSobre los autoresFundamentos del diseo de computadoresIntroduccionDefiniciones de rendimientoPrincipios cuantitativosdel diseo de computadoresEl trabajo de un diseador de computadoresJuntando todo: el concepto de jerarqua de memoriaFalaciasy pifiasObservaciones finalesPerspectiva histricay referenciasEjerciciosRendimientosy coste2.1 Introduccin2.2 Rendimiento2.3 Coste2.4 Juntando todo: precio/rendimientode tres mquinas2.5 Falaciasy pifias2.6 Observaciones finales2.7 Perspectiva histricay referenciasEjerciciosDiseo de repertoriosde instrucciones:alternativasy principios3.1 Introduccion3.2 Clasificacin de las arquitecturas a nivel lenguaje mquina3.3 Almacenamiento de operandos en memoria: clasificacindelas mquinas de registros de propsito general3.4 Direccionamiento de memoria3.5 Operaciones del repertorio de instrucciones3.6 Tipo y tamao de los operandos3.7 El papel de los lenguajes de alto nivel y compiladoresviixxixxvi 10. X CONTENIDO3.8 Juntando todo: cmo los programas utilizan los repertoriosde instrucciones3.9 Falacias y pifias3.10 Observaciones finales3.11 Perspectiva histricay referenciasEjerciciosEjemplosy medidas de utilizacinde los repertoriosde instruccionesMedidas de los repertorios de instrucciones:qu y por quLa arquitectura VAXLa arquitectura 3601370La arquitectura 8086La arquitectura DLXJuntando todo: medidas de utilizacin del repertorio deinstruccionesFalaciasy pifiasObservaciones finalesPerspectivahistricay referenciasEjerciciosTcnicas bsicas de implementacinde procesadores5.1 Introduccin5.2 Camino de datos del procesador5.3 Pasos bsicos de ejecucin5.4 Controlcableado5.5 Control microprogramado5.6 Interrupcionesy otros enredos5.7 Juntando todo: control para DLX5.8 Falacias y pifias5.9 Observacionesfinales5.10 Perspectiva histrica y referenciasEjerciciosSegmentacinQu es la segmentacin?Segmentacin bsica para DLXHaciendo que funcione la segmentacinEl principalobstculo de la segmentacin: riesgos de lasegmentacinQu hace difcil de implementarla segmentacionExtensin de la segmentacin de DLX para manipularoperaciones multicicloSegmentacin avanzada: planificacindinmica de lasegmentacionSegmentacin avanzada: aprovechando ms el paralelismode nivel de instruccinJuntando todo: un VAX segmentadoFalacias y pifiasObservaciones finales 11. 6.12 Perspectiva histricay referenciasEjerciciosProcesadores vectorialesPor que mquinas vectoriales?Arquitectura vectorial bsicaDos aspectos del mundo real: longitud del vector yseparacin entre elementosUn modelo sencillo para el rendimiento vectorialTecnologa de compiladores para mquinas vectorialesMejorando el rendimiento vectorialJuntando todo: evaluacin del rendimiento de losprocesadoresvectorialesFalaciasy pifiasObservaciones finalesPerspectiva histricay referenciasEjerciciosDiseode la jerarqua de memoriaIntroduccin:principio de localidadPrincipios generales de jerarqua de memoriaCachesMemoriaprincipalMemoriavirtualProtecciny ejemplos de memoriavirtualMs optimizaciones basadas en el comportamientode losprogramasTpicos avanzados. Mejora del rendimiento de memoriacache8.9 Juntando todo: la ierarquia de memoria del VAX-11/7808.10 Falaciasy pifias8.11 Observaciones finales8.12 Perspectiva histricay referenciasEjerciciosIntroduccinPrediccindel rendimiento del sistemaMedidas de rendimiento de E/STipos de dispositivos de E/SBuses. Conectandodispositivos de E/S a CPU/memorialnterfaz con la CPUlnterfaz con un sistema operativoDiseo de un sistema de E/SJuntando todo: el subsistema de almacenamiento IBM 3990Falaciasy pifiasObservaciones finalesPerspectiva histricay referenciasEjercicios 12. x CONTENIDO10 Tendenciasfuturas10.1 Introduccin10.2 Clasificacinde Flynn de los computadores10.3 Computadores SIMD. Flujo nico de instrucciones,flujosmltiples de datos10.4 Computadores MIMD. Flujos mltiples de instrucciones,flujos mltiples de datos10.5 Las rutas a El Dorado10.6 Procesadoresde propsito especial10.7 Direcciones futuras para los compiladores10.8 Juntando todo: el multiprocesador Sequent Symmetry10.9 Falaciasy pifias10.10 Observaciones finales. Evolucin frente a revolucin enarquitectura de computadores10.11 Perspectiva histricay referenciasEjerciciosApndice A: Aritmbtica de computadorespor DAVID GOLDBERGXerox Palo Alto ResearchCenterIntroduccinTcnicas bsicas de la aritmtica enteraPunto flotanteSuma en punto flotanteMultiplicacin en punto flotanteDivisin y restoPrecisionesy tratamiento de excepcionesAceleracin de la suma enteraAceleracin de la multiplicaciony divisin enterasJuntando todoFalaciasy pifiasPerspectiva histricay referenciasEjerciciosApndice 6: Tablas completas de repertoriosde instruccionesB.l Repertoriode instruccionesde usuariodel VAX8.2 Repertoriode instruccionesdel sistema/360B.3 Repertoriode instruccionesdel 8086Apndice C: Medidasdetalladas del repertoriode instruccionesC.1 Medidas detalladas del VAXC.2 Medidas detalladas del 360C.3 Medidas detalladas del lntel 8086C.4 Medidas detalladas del repertoriode instruccionesdel DLXApndice D: Medidasde tiempo frentea frecuenciaD.l Distribucin de tiempos en el VAX-111780 13. CONTENIDO xiiiD.2 Distribucinde tiempos en el IBM 3701168D.3 Distribucinde tiempos en un 8086 de un IBM PCD.4 Distribucin de tiempos en un procesador prximo a DLXApndice E: Visin general de lasarquitecturasRlSCIntroduccinModos de direccionamiento y formatos de instruccinInstrucciones:el subconjunto de DLXInstrucciones:extensiones comunes a DLXlnstruccionesnicas del MlPSlnstruccionesnicas del SPARClnstruccionesunicas del M88000lnstruccionesnicas del i860Observaciones finalesReferenciasDefiniciones de arquitectura de computadores,trivialidades,frmulas y reglas empricasNotacinde descripcion hardware (y algunos operadores Cesthndares)Estructura de la segmentacin del DLXRepertorio de instruccionesdel DLX, lenguaje de descripcin ysegmentacin del DLXReferenciaslndice 14. -1 PrlogoComenc en 1962 a escribir un sencillo libro con esta secuencia de captulos,pero pronto me di cuenta que era ms importante tratar en profundidad lostemas mejor que pasar casi tocndolos ligeramente. El tamao resultante hahecho que cada captulo,por s mismo, contenga suficiente material para uncurso semestral;por ello se ha hecho necesario publicar la serie en volmenesseparados...Donald Knuth, TheArt of Computer Programming.Prlogo al Volumen 1 (de 7) (1968)Por que escribimos este libro?Bienvenidos a este libro! Estamos contentos de tener la oportunidad de co-municar con usted! Hay muchas cosas excitantes que ocurren en la arquitec-tura de computadores, pero somos conscientes que los materiales disponiblesno hacen que la gente se d cuenta de esto. Esta no es una ciencia aburrida demquinas de papel que nunca funcionan. NO!Es una disciplina de gran in-ters intelectual, que requiere equilibrar las fuerzas del mercado y del coste/rendimiento, llevando a fallos gloriosos y a algunos xitos notables. Y es difi-cil imaginar la excitacin de ver a miles de personas utilizar la mquina queusted dise.Nuestro objetivoprincipal al escribir este libro es ayudar a cambiar la formaen que se aprende la arquitectura de computadores. Pensamos que el campoha cambiado desde que slo se poda ensear con definiciones e informacinhistrica, hasta ahora que se puede estudiar con ejemplos reales y medidasreales. Pensamos que este libro es aconsejable para un curso sobre arquitec-tura de computadores, as como un libro de texto o referencia para ingenierosprofesionales y arquitectos de computadores. Este libro incorpora una nuevaaproximacin para desmitificar la arquitectura de computadores -hace n-fasisen una aproximacin cuantitativa de las relaciones de coste/rendimiento.Esto no implica una aproximacin demasiado formal, sino simplemente la quese basa en buen diseo de ingeniera. Para lograr esto, hemos incluido muchosdatos sobre mquinas reales, para que el lector pueda comprender la din-mica de un diseo. de forma tanto cuantitativa como cualitativa. Un com- 15. XV PROLOGOponente significativode esta aproximacin se puede encontrar en las coleccio-nes de problemas al final de cada captulo. Los ejercicios han constituido elncleo de la educacin en ciencia e ingeniera. Con la aparicin de una basecuantitativa para ensear arquitecturade computadores, nos damos cuenta queel campo tiene potencial para desplazarse hacia los fundamentos rigurososcuantitativosde otras disciplinas.Organizacin y seleccinde tpicosHemos adoptado una aproximacin conservadora para la seleccin de tpi-cos, ya que hay muchas ideas interesantesen este campo. Mejor que intentaruna visin general comprensiva de cada arquitectura que un lector pueda en-contrar en la prctica o en la literatura actual, hemos seleccionadolosconcep-tos fundamentales de arquitectura de computadores que, probablemente, sevan a incluir en cualquier mquina nueva. Para tomar estas decisiones, uncriterio clave ha sido hacer nfasis en ideas que se han examinado suficiente-mente como para ser explicadas en trminos cuantitativos. Por ejemplo, nosconcentramos en los uniprocesadores hasta el captulo final, donde se describeun multiprocesador de memoria compartida orientado a bus. Pensamos queesta clase de arquitectura de computador aumentar en popularidad, pero apesar de esta percepcin, slo responda a nuestro criterioen un estrechomar-gen. Slo recientementese ha examinado esta clase de arquitectura en formasque nos permiten discutirla cuantitativamente; incluso hace poco tiempo to-dava esto no se poda haber incluido. Aunque los procesadores paralelos engran escala son de importancia obvia para el futuro, creemosque es necesariauna base firme en los principios del diseo de uniprocesadores, antes quecualquier ingeniero en ejercicio intente construir un computador mejor decualquier organizacin; especialmente, incorporando mltiples uniprocesa-dores.Los lectores familiarizadoscon nuestra investigacin pueden esperar queeste libro trate slo sobre computadores de repertorio de instrucciones redu-cido (RISC). Esto es un juicio errneo sobre el contenido del libro. Nuestraesperanza es que los principiosde diseno y los datos cuantitativos de este librorestrinjan las discusiones sobre estilos de arquitectura a trminos como msrpido o ms barato, de forma distinta a debates anteriores.El material que hemos seleccionado se ha ampliado hasta una estructuraconsistenteque se sigue en cada captulo. Despus de explicar las ideas de uncaptulo, incluimos una seccin de Juntando todo, que liga las ideas ex-puestas para mostrar cmo se utilizan en una mquina real. A continuacin,sigue una seccin, titulada Falacias y pifias~,que permite que los lectoresaprendan de los errores de los dems. Mostramos ejemplosde errores comu-nes y pifias en arquitectura que son difciles de evitar aun cuando el lectorsepa que le estn esperando. Cada captulo finaliza con una seccin de Ob-servaciones finales, seguida por una seccin de Perspectiva histrica y refe-rencias~que intenta dar crditoadecuado a las ideas del captulo y un sentidode la historia circundante a las invenciones, presentando el drama humanodel diseo de computadores. Tambin proporciona referencias que el estu-diante de arquitectura puede desear conseguir. Si tiene tiempo, le recomen- 16. PROLOGO XVdamos leer algunosde los artculos clsicos en este campo, que se mencionanen estas secciones. Es divertido y educativo or las ideas de boca de los crea-dores. Cada captulo finaliza con Ejercicios, unos doscientosen total, que va-ran desde revisiones de un minuto a proyectos de un trimestre.Un vistazo a la Tabla de contenidos muestra que ni la cantidad ni la pro-fundidad del material es igual de un captulo a otro. En los primeros captu-los, por ejemplo, tenemos material bsico para asegurar una terminologa yconocimientoscomunes bsicos. Al hablar con nuestroscolegas,encontramosopiniones que varan ampliamente sobre los conocimientos bsicos que tie-nen los lectores, el ritmo al que pueden captar el nuevo material, e incluso elorden en que se deben introducir las ideas. Nuestra hiptesis es que el lectorest familiarizadocon el diseo lgico, y tiene conocimiento, al menos, de unrepertorio de instrucciones y conceptos bsicos de software. El ritmo vana conlos captulos, siendo la primera mitad ms pausada que la segunda. Las deci-siones sobre la organizacinse tomaron en respuesta a las advertenciasde losrevisores. La organizacin final se seleccion para seguir adecuadamente lamayora de los cursos (jadems de Berkeley y Stanford!)con slo pequeasmodificaciones. Dependiendo de sus objetivos, vemos tres caminos a travsde este material:Cobertura introductoria: Captulos 1,2, 3,4, 5, 6.1-6.5, 8.1-8.5,9.1-9.5,10, y A.l-A.3.Cobertura intermedia: Captulos 1,2, 3,4, 5,6.1-6.6,6.9-6.12,8.1-8.7,8.9-8.12, 9, 10, A (excepto la divisin en laSeccinA.9) y E.Cobertura avanzada: Leer todo, pero los Captulos 3 y 5 y lasSeccionesA.1-A.2 y 9.3-9.4 pueden ser en sumayor parte una revisin, as que lalas rpi-damente.Desgraciadamente, no hay un orden ideal para los captulos. Sera agra-dable conocer algo sobre segmentacin (Cap. 6) antes de explicar repertoriosde instrucciones(Caps. 3 y 4), por ejemplo, pero es dificil comprender la seg-mentacin sin comprender el repertorio completo de instruccionesque se estsegmentando.En versiones anteriores hemos intentado diversas ordenacionesde este material, y cada una tena sus ventajas. Por ello, el material se ha es-crito para que se pueda cubrir de varias formas. La organizacin ha probadoser suficientementeflexible para una gran variedad de secuenciasde captulosen el programa de examen Betm en 18 escuelas, donde el libro se utiliz conxito. La nica restriccin es que algunos captulos deben ser ledos en se-cuencia:Captulos 1y 2Captulos 3 y 4Captulos 5, 6 y 7Captulos 8 y 9 17. XV PROLOGOLos lectores deberan comenzar con los Captulos 1 y 2 y finalizar con elCaptulo 10, pero el resto se puede cubrir en cualquier orden. La nica salve-dad es que si se leen los Captulos 5, 6 y 7 antes que los Captulos 3 y 4, sedebera examinar primero la Seccin 4.5, ya que el repertorio de instruccionesde esta seccin, DLX, se utiliza para ilustrar las ideas que aparecen en esostres captulos. Una descripcin compacta de DLX y de la notacin de descrip-cin hardware que utilizamos puede encontrarse en la contraportada poste-rior. (Seleccionamos una versin modificada de C para nuestro lenguaje dedescripcin hardware debido a: su compacidad, al nmero de personas queconoce el lenguaje y a que no hay lenguaje de descripcin comn utilizado enlibros que se puedan considerar prerrequisitos.)Recomendamos encarecidamente a todos la lectura de los Captulos 1 y 2.El Captulo 1 es intencionadamente fcil de seguir, ya que puede leerse rpi-damente, incluso por un principiante. Da algunos principios importantes queactan como temas que guan la lectura de captulos posteriores. Aunque po-cos se saltaran la seccin de rendimiento del Captulo 2, algunos pueden estartentados.de saltar la seccin de coste para ir a las cuestiones tcnicas de loscaptulos finales. Por favor, no lo haga. El diseo de computadores es casisiempre un intento de equilibrar coste y rendimiento, y pocos comprendencmo el precio se relaciona con el coste, o cmo bajar en un 10por 100 costey precio, y de qu forma se minimiza la prdida de rendimiento. Los funda-mentos que se proporcionan, en la seccin de coste del Captulo 2, permitenque el coste/rendimiento sea la base de todos los compromisos en la segundamitad del libro. Por otro lado, probablemente sea mejor dejar algunas cuestio-nes como material de referencia. Si el libro es parte de un curso, las clasespueden mostrar cmo utilizar los datos desde estos captulos para tomar de-cisionesen el diseo de computadores. El Captulo 4 quiz sea el mejor ejem-plo de esto. Dependiendo de los conocimientos bsicos, el lector puede estarya familiarizado con parte del material, pero tratamos de incluir algunas pe-culiaridades para cada materia. La seccin sobre microprogramacin delCaptulo 5 ser un repaso para muchos, por ejemplo, pero la descripcin delimpacto de las interrupciones sobre el control raramente se encuentra en otroslibros.Tambin realizamos un esfuerzo especial en hacer este libro interesantepara los ingenieros en ejercicio y estudiantes avanzados. Secciones de temasavanzados se encuentran en:Captulo 6, sobre segmentacin (Secciones 6.7 y 6.8, que son aproxima-damente la mitad del captulo).Captulo 7, sobre vectores (el captulo completo).Captulo 8, sobre diseo de jerarquas de memoria (Seccin 8.8, que esaproximadamente un tercio del Captulo 8).Captulo 10, sobre direcciones futuras (Seccin 10.7, aproximadamente uncuarto de ese captulo).Aquellos que, por presin del tiempo, quieran saltar algunas de estas sec-ciones, para hacer el salto ms fcil, las seccionesde Juntando todo de losCaptulos 6 y 8 son independientes de los temas avanzados. 18. PROLOGO XXEl lector puede haber observado que el pu>to flotante se cubre en elApndice A en lugar de en un captulo. Como esto es muy independiente delmaterial restante, nuestra solucin fue incluirlo como un apndice cuandonuestras informaciones indicaron que un porcentaje significativo de los lec-tores tenan conocimientos sobre punto flotante.Los apndices restantes se incluyen tanto como referencias para los pro-fesionalesde los computadores como para los Ejercicios. El Apndice B con-tiene los repertorios de instrucciones de tres mquinas clsicas: la IBM 360, elIntel 8086 y la DEC VAX. Los Apndices C y D dan la mezcla de instruccio-nes de programas reales para estas mquinas ms DLX, medidas por frecuen-cia de instrucciones o por frecuencia de tiempo. El Apndice E ofrece una vi-sin comparativa, ms detallada, de algunas arquitecturas recientes.Ejercicios, proyectos y softwareLa naturaleza opcional del material tambin se refleja en los Ejercicios. Loscorchetes para cada pregunta (captulo.seccin) indican las seccionesde textode relevancia principal para responder la pregunta. Esperamos que esto ayudea los lectores a evitar ejerciciospara los cuales no han ledo la seccin corres-pondiente, as como suministrar la fuente para revisin. Hemos adoptado latcnica de Donald Knuth de puntuar los Ejercicios. Las puntuaciones dan unaestimacin de la cantidad de esfuerzo que puede llevar un problema:[lo] Un minuto (lectura y comprensin).[20] De quince a veinte minutos para la respuesta completa.[25] Una hora para escribir la respuesta completa.[30] Proyecto corto de programacin: menos de un da completo de pro-gramacin.[40] Proyecto significativode programacin: dos semanas de tiempo derealizacin.[50] Proyecto largo (de dos a cuatro semanas para dos personas).[Discusin] Tpico para discusin con otros interesados en arquitecturade computadores.Observaciones finalesEste libro es inusual, ya que no hay orden estricto en los nombres de losautores. La mitad de las veces aparecer Hennessy y Patterson, tanto en estelibro como en los anuncios, y la otra mitad aparecer Patterson y Hennessy.Incluso aparecern ambas formas en las publicacionesbibliogrficastales comoLibros en Impresin. (Cuando referenciamos el libro, alternamos el orden delos autores.) Esto refleja la verdadera naturaleza colaboradora de este libro:juntos, reflexionamos sobre las ideas y mtodos de presentacin, despus, in-dividualmente, cada uno escribi una mitad de los captulos y actu como re- 19. XX PROLOGOvisor del borrador de la otra mitad. (En efecto, el nmero final de pginassugiere que cada uno escribi el mismo nmero de pginas!) Pensamos que lamejor forma de reflejar esta genuina cooperacin es la de no ocultarse en laambigedad -una prctica que puede ayudar a algunos autores pero con-funde a los bibliotecarios. Por ello, compartimosigualmente la culpa de lo queest a punto de leer.JOHNHENNESSY DAVIDPATTERSONEnero 1990 20. 1 AgradecimientosEste libro se escribi con la ayuda de gran nmero de personas -tantas, enefecto, que algunos autores podran detenerse aqu, indicando que eran de-masiadas para ser nombradas. Sin embargo, declinamos utilizar esa excusa,porque se ocultara la magnitud de la ayuda que necesitamos. Por ello, cita-mos a las 137personasy cinco institucionesa las que tenemos que dar las gra-cias.Cuando decidimos aadir un apndice sobre punto flotante, que caracte-rizase el estndar del IEEE, pedimos a muchos colegasque nos recomendasenuna persona que comprendieseese estndar y que pudiese escribir bien y ex-plicar con sencillezcomplejasideas. David Goldberg, de Xerox Palo Alto Re-search Center, realiz todas estas tareas admirablemente, poniendo un nivelal que esperamosse encuentre el resto del libro.Margo Seltzer de la U.C. Berkeley merece un reconocimiento especial. Noslo porque fue la primera profesora ayudante del curso en Berkeley que uti-liz el material, sino porque reuni todo el software, benchmarks y trazas.Tambin ejecut las simulacionesde las caches y del repertorio de instruccio-nes que aparecen en el Captulo 8. Le agradecemos su prontitud y fiabilidadal seleccionar partes de softwarey juntar todo en un paquete coherente.Bryan Martin y Truman Joe de Stanford tambin merecen nuestro agra-decimiento especial por leer rpidamente los Ejercicios de los primeros cap-tulos poco antes de publicar el libro. Sin su dedicacin, los Ejercicioshabranestado considerablementemenos pulidos.Nuestro plan para desarrollareste material fue ensayar primero las ideas afinales de 1988en los cursos que impartamos en Berkeley y Stanford. Crea-mos notas de clase; primero las ensayamos con los estudiantes de Berkeley(porque el ao acadmico en Berkeley comienza antes que en Stanford), de-tectando algunos errores, y despus exponiendo estas ideas a los estudiantesde Stanford. Esta puede no haber sido la mejor experiencia de sus vidas aca-dmicas, por ello deseamos dar las gracias a aquellos que voluntariamentefueron conejillos de indias; as como a los profesores ayudantes Todd Narter,Margo Seltzer y Eric Williams, que sufrieronlas consecuencias del desarrollode esta experiencia.El siguiente paso del plan fue redactar un borrador del libro durante el in-vierno de 1989.Esperbamoshacerlo pasando a limpio las notas de clase, peronuestra realimentacin de los estudiantes y la reevaluacin, que es parte decualquier redaccin, convirti esto en una tarea mucho ms amplia de lo que 21. XX AGRADECIMIENTOSesperbamos. Esta versin Alpha se envi a los revisores en la primavera de1989. Nuestro agradecimiento especial a Anoop Gupta de la Universidad deStanford y a Forest Baskett de Silicon Graphics, que utilizaron la versinAlpha para impartir una clase en Stanford en la primavera de 1989.La arquitectura es un campo que tiene una cara acadmica y otra indus-trial. Nos relacionamos con ambos tipos de expertos para revisar el materialde este libro. Los revisores acadmicos de la versin Alphm incluyen a Tho-mas Casavant de la Universidad de Purdue, Jim Goodman de la Universidadde Wisconsin en Madison, Roger Keickhafer de la Universidad de Nebraska,Hank Levy de la Universidad de Washington, Norman Matloff de la Univer-sidad de California en Davis, David Meyer de la Universidad de Purdue, Tre-vor Mudge de la Universidad de Michigan, Victor Nelson de la Universidadde Auburn, Richard Reid de la Universidad del Estado de Michigan y MarkSmotherman de la Universidad de Clemson. Tambin deseamos dar las gra-cias a aquellos que nos comentaron nuestro borrador a finales del ao 1989:Bill Dally del MIT, y Jim Goodman, Hank Levy, David Meyer y JosephPfeiffer del Estado de Nuevo Mxico. En abril de 1989, algunos de nuestrosplanes fueron examinados en un grupo de discusin que inclua a Paul Barrde la Universidad del Noreste, Susan Eggers de la Universidad de Washing-ton, Jim Goodman y Mark Hill de la Universidad de Wisconsin, James Moo-ney de la Universidadde Virginia Oeste, y Larry Wittie de SUNY Stony Brook.Apreciamos sus valiosas sugerencias.Antes de citar a los revisores industriales, nuestro especial agradecimientoa Douglas Clark de DEC, que nos dio ms comentarios sobre la versinAlpha que los dems revisores juntos, y cuyas observaciones fueron siem-pre escritas cuidadosamente teniendo en cuenta nuestra naturaleza sensible.Otras personas que revisaron algunos captulos de la versin Alpha fueronDavid Douglas y David Wells de Thinking Machines,Joel Emer de DEC, EarlKillian de MIPS Computer SystemsInc., y Jim Smith de Cray Research. EarlKillian tambin explic los misterios del analizador del repertorio de las ins-trucciones Pixie y nos proporcion una versin no publicada para recogerestadsticasde saltos.Tambin damos las gracias a Maurice Wilkes de Olivetti Research y aC. Gordon Bell de Stardent por ayudarnos a mejorar nuestras versiones de lahistoria de los computadores al final de cada captulo.Adems de aquellos que, voluntariamente, leyeron muchos captulos,tambin deseamos dar las gracias a los que nos hicieron sugerenciasdel ma-terial a incluir o revisaron la versin Alpha de los captulos:Captulo 1: Danny Hillis de Thinking Machines por sus sugerenciassobre la asignacinde recursos, de acuerdo con su contribucin al rendimiento.Captulo 2: Andy Bechtolsheim de Sun Microsystems por sus sugerencias del preciofrente al coste y las estimaciones de coste de las estacionesde trabajo; David Hodges dela Universidad de California en Berkeley, Ed Hudson y Mark Johnson de MIPS, AlMarston y Jim Slager de Sun, Charles Stapper de IBM, y David Wells de ThinkingMachinespor explicarel rendimiento y fabricacin de los circuitos integrados: Ken Lutzde la U.C. Berlekey y el servicio de circuitos integrados FAST de USC/ISI por las citasde precios de los chips; Andy Bechtolsheim y Nhan Chu de Sun Microsystems, DonLewine de Data General, y John Mashey y Chris Rowen de MIPS que tambin revi-saron este captulo. 22. AGRADECIMIENTOS XXCaptulo 4: Tom Adams de Apple y Richard Zimmermannde la Universidad del Estadode San Francisco por sus estadsticasdel Intel 8086;John Crawfordde Intel por revisarel 80x86 y otros materiales; Lloyd Dickman por revisar el material de la IBM 360.Captulo 5: Paul Carrick y Peter Stoll de Intel por las revisiones.Capitulo 7: David Bailey de NASA Ames y Norm Jouppi de DEC por las revisiones.Capitulo 8: Ed Kelly de Sun por su ayuda en la explicacin de las alternativas de lasDRAM y Bob Cmelik de Sun por las estadsticas de SPIX; Anant Agarwal de MIT,Susan Eggers de la Universidad de Washington, Mark Hill de la Universidad de Wis-consin en Madison, y Steven Przybylski de MIPS por el material de sus disertaciones;y Susan Eggers y Mark Hill por las revisiones.Capitulo 9: Jim Brady de IBM por proporcionar referencias cuantitativas para datossobre tiempo de respuesta y computadores IBM y revisar el captulo; Garth Gibson dela Universidad de California en Berkeley por ayudarnos con las referencias del bus ypor revisar el captulo; Fred Berkowitz de Omni Solutions, David Boggs de DEC, PeteChen y Randy Katz de la Universidad de California en Berkeley, Mark Hill de la Uni-versidad de Wisconsin, Robert Shomler de IBM, y Paul Taysom de AT&T Be11 Labo-ratones por las revisiones.Captulo 10: C. Gordon Bell de Stardent por su sugerenciade incluir un multiprocesa-dor en la seccin de Juntando todo; Susan Eggers, Danny Hills de Thinking Machi-nes, y Shreekant Thakkarde Sequent Computer por las revisiones.Apndice A: Los datos sobre REM IEEE y la reduccin de argumentosen la SeccinA.6,as como el teorema p6(q- 1)/2 (pg. 671)se tomaron de notas de clase no publicadasde William Kahan de la U.C. Berlekey (y no sabemos de ninguna fuente publicada quecontenga una explicacinde estos aspectos).El dato de SDRWAVEes de David Houghde Sun Microsystems.Mark Birrnan de Weitek Corporation, Merrick Darley de TexasInstruments, y Mark Johnson de MIPS proporcionaron informacin sobre el: 3364,8847 y R3010, respectivamente. William Kahan tambin ley un borrador de este ca-ptulo e hizo muchos comentarios tiles. Tambin agradecemosa Forrest Brewer de laUniversidad de California en Santa Barbara, Milos Ercegovac de la Universidad de Ca-lifornia en Los Angeles, Bill Shannon de Sun Microsystems, y Behrooz Shirazi de laUniversidad Metodista del Southern por las revisiones.Aunque muchos nos advirtieron de que ahorrsemos esfuerzos y public-semos el libro lo antes posible, perseguamosel objetivo de publicar el libro loms claro posible con la ayuda de un grupo adicional de personas involucra-das en la ronda final de revisiones. Este libro no sena tan til sin la ayuda deinstructores atrevidos, profesores ayudantes, y estudiantes trabajadores, queaceptaron el papel del examen Beta en el programa de examen de clase; rea-lizamos cientos de cambios como resultado del test Betm. Las institucionese instructores del test Beta fueron:Universidad de Carnegie-Mellon Daniel SiewiorekUniversidad de Clemson Mark SmothermanUniversidad de Cornell Keshav PingaliUniversidad del Estado de Pennsylvania Mary Jane Irwin/Bob OwensUniversidad del Estado de San Francisco Vojin OklobdzijaUniversidad Sureste del Estado deMissouri Anthony DubenUniversidad Meridional Metodista Behreoz ShiraziUniversidad de Stanford John HennessyUniversidad del Estado de Nueva Yorkde Stony Brook Larry Wittie 23. X ~ V AGRADECIMIENTOSUniversidad de Califomia de BerkeleyUniversidad de Californiade Los AngelesUniversidad de Californiade Santa CruzUniversidad de NebraskaUniversidad de Carolina del Norte deChape1 HillUniversidad de Texas de AustinUniversidad de Water100Universidad de Wisconsin de MadisonUniversidad de Washington (St. Louis)Vojin OklobdzijaDavid RennelsDaniel HelmanRoger KieckhaferAkhilesh TyagiJosep RamehBruno PreissMark HillMark FranklinMencin especial merecen Daniel Helman, Mark Hill, Mark Smother-man y Larry Wittie que fueron especialmente generosos con sus sugerencias.A la compilacinde las solucionesde los ejerciciospara los instructoresde loscursos contribuyeron Evan Tick de la Universidad de Oregon, Susan Eggersde la Universidad de Washington,y Anoop Gupta de la Universidad de Stan-ford.Las clases en SUNY Stony Brook, Carnegie-Mellon, Stanford, Clemson yWisconsin nos proporcionaron el mayor nmero de descubrimientosde erro-res en la versin Betm. Nos gustara hacer notar que se encontraron nume-rosos errores y los corrigieron las siguientes personas: Michael Butler, RohitChandra, David Cummings, David Filo, Carl Feynman, John Heinlein, JimQuinlan, Andras Radics, Peter Schnorf y Malcolm Wing.Adems de los exmenesde clase, tambin pedimos nuevamenteayuda anuestrosamigosde la industria. Nuestro agradecimientoa Jim Smith de CrayResearch por su minuciosa revisin y sus previsoras sugerencias del textocompleto Betan. Las siguientespersonas tambin nos ayudaron a mejorar laversin Betm, y se lo agradecemos:Ben Hao de Sun Microsystems por revisar la versin Beta completa.Ruby Lee de Hewlett-Packardy Bob Supnik de DEC por revisar algunoscaptulos.Captulo 2: Steve Goldstein de Ross Semiconductory Sue Stone de Cypress Semi-conductor por las fotografasy la oblea del CY7C601 (pgs. 61-62);John Crawfordy Jacque Jarve de Intel por las fotografasy obleas del Intel 80486 (pgs. 60-62);yDileep Bhandarkarde DECpor ayudamos con la versin VMS de Spicey TeX uti-lizadas en los Captulos 2-4.Captulo 6: John DeRosa de DEC por ayudarnos con la segmentacin del 8600.Captulo 7: Corinna Lee de la Universidad de California en Berkeley por las me-didas de los Cray X-MP e Y-MP y por las revisiones.Captulo 8: Steve Przybylski de MIPS por las revisiones.Captulo 9: Dave Anderson de Impnmis por las revisiones y por suministrarnosmaterial sobre tiemposde acceso al disco;Jim Brady y Robert Shomlerde IBM porlas revisiones,y Pete Chen de Berkeley por las sugerencias en las frmulas de ren-dimiento del sistema.Captulo 10: C. Gordon Bell por las revisiones, incluyendo algunas sugerencias so-bre las clasificacionesde las mquinas MIMD, y David Douglas y Danny Hillis deThinking Machines por las explicaciones sobre procesadores paralelos del futuro.Apndice A: Mark Birman de Weitek Corporation, Merrick Darley de Texas Ins-truments, y Mark Johnson de MIPS por las fotografas y planos de planta de loschips (pgs. 641); y David Chenevert de Sun Microsystems por las revisiones. 24. AGRADECIMIENTOS XXVApndice E: Se aadi despus de la versin Betan, y agradecemos a las siguientespersonas sus revisiones: Mitch Alsup de Motorola, Robert Garner y David Weaverde Sun Microsystems, Earl Killian de MIPS Computer Systems, y Les Kohn de In-tel.Aunque hemos hecho todo lo posible para eliminar los errores y para co-rregir los sealadospor los revisores, Slo nosotros somos responsables de todolo que queda!Tambin queremos agradecer a la Defense Advanced Research ProjectsAgency~por soportar nuestra investigacin durante muchos aos. Esa inves-tigacin fue la base de muchas ideas que aparecen en este libro. En particular,queremos dar las gracias a los gestores actuales y anteriores del programa:Duane Adams, Paul Losleben, Mark Pullen, Steve Squires, Bill Bandy y JohnToole.Nuestro agradecimiento a Richard Swan y sus colegas de DEC Western .Research Laboratory por proporcionarnos un escondrijopara escribir las ver-siones iAlphm y Betm, y a John Ousterhoutde la U.C.Berkeley, que siem-, pre estuvo dispuesto (e incluso un poco impaciente) para actuar como abo-gado del diablo por los mritos de las ideas de este libro durante este viaje deBerkeley a Palo Alto. Tambin damos las gracias a Thinking Machines Cor-poration por proporcionarnos un refugio durante la revisin final.Este libro no se podna haber publicado sin un editor. John Wakerley nosdio valiosos consejos sobre cmo encontrar un editor. Seleccionamos a Mor-gan Kaufmann Publishers, Inc., y no nos arrepentimos de esa decisin. (NOtodos los autores piensan de esta forma acerca de su editor!)Comenzando connotas de clasejusto despus del Da de Ao Nuevo de 1989, completamos laversin Alpha en cuatro meses. En los tres meses siguientes recibimos re-visiones de 55 personas y terminamos la versin Betax Despus de los ex-menes de clase con 750 estudiantes a finales de 1989 y ms revisiones de laindustria, conseguimos la versin final justo antes de las Navidades de 1989.Con todo, el libro estuvo disponible en marzo de 1990. No conocemos otroeditor que llevase el mismo paso con una planificacin rigurosa. Deseamosagradecer a Shirley Jowell el aprendizaje sobre segmentacin y riesgos en lasegmentacin y ver cmo aplicarlos para editarlos. Nuestro agradecimientoms caluroso a nuestro editor Bruce Spatz por su gua y su humor en nuestraaventura de escritores. Tambin queremos dar las gracias a los miembros dela amplia familia de Morgan Kaufmann: Walker Cunningham por la edicintcnica, David Lance Goines por el diseo de la cubierta, Gary Head por eldiseo del libro, Linda Medoff por la edicin de produccin y copia, FifthStreet Computer Services por el mecanografiadoy Paul Medoff por las prue-bas de lectura y asistencia de produccin.Tambin debemos dar las gracias a nuestro staffi>de la universidad,Dar-lene Hadding, Bob Miller, Margaret Rowland y Terry Lessard-Smith por losinnumerables faxes y correos express, as como por encargarse del trabajoen Stanford y Berkeley mientras trabajamos en el libro. Linda Simko y KimBarger de Thinking Machines tambin nos proporcionaron numerosos co-rreos express durante el otoo.Finalmente, graciasa nuestras familias por su paciencia a lo largo de largasnoches y tempranas maanas de lectura, mecanografiadoy abandono. 25. 1 Sobre los autoresDAVID A. PATTERSON (Universidad de California en Berkeley) ha ense-ado arquitectura de computadores desde su incorporacin al cuerpo docenteen 1977, y actualmente es presidente de la divisin de Informtica. Ha sidoconsultor de algunas compaas, incluyendo Digital Equipment Corporation,Intel y Sun Microsystems. El doctor Patterson es tambin ((CorporateFellowde Thinking Machines y miembro del ((Scientific Advisory Board de DataGeneral. Ha sido galardonado por la Universidad de California con el Di+tinguished TeachingAward y es Fellow del Institute of Electncal and Elec-tronic Engineers.En Berkeley dirigi el diseo e implementacin del RISC 1, probable-mente el primer computador VLSI de repertorio de instrucciones reducido.Ms tarde, sus proyectos produjeron varias generaciones de RISC, as comodos adistinguished disertation awardsn de la Association for Computing Ma-chinery (ACM). Esta investigacinconstituy los fundamentos de la arquitec-tura SPARC, actualmente utilizada por AT&T, Fujitsu, ICL, LSI Logic, Phi-lips, Sun, TI y Xerox. Su investigacin actual se centra en el desarrollo denuevos sistemasde entrada/salida para incrementarel rendimientode las CPU.JOHN L. HENNESSY (Universidad de Stanford) ha sido miembro del cuerpodocente desde 1977. Es director del Computer Systems Laboratory en Stan-ford, donde ensea arquitectura de computadores y supervisa un grupo de es-tudiantesde doctorado. Es el titular actual de la ctedra Willard R. e Inez KerrBe11de la Escuela de Ingeniera.El rea de investigacin original de Hennessy fue la optimizacin de com-piladores. Su grupo de investigacin en Stanforddesarrollmuchas de las tc-nicas que ahora se usan comercialmente.En 1981 comenz el proyecto MIPSen Stanford con un grupo de estudiantesgraduados. Despus de completar elproyecto en 1984,dej un ao la universidad y fue uno de los fundadores deMIPS Computer Systems. La arquitectura RISC desarrolladaen MIPS ha sidoadoptada por una serie de compaas, entre las que se encuentran DEC, Ho-neywell-Bull, NEC, Siemens, Silicon Graphics y Tandem. Contina ejer-ciendo como jefe cientfico en MIPS. Su investigacin actual en Stanford sedirige al rea del diseo y explotacinde multiprocesadores. 26. Y ahora algo completamentediferente.Circovolante de Monty Python.IntroduccinDefinicionesde rendimientoPrincipioscuantitativos del diseo de computadoresEltrabajo de un diseador de computadoresJuntando todo: el conceptode jerarqua de memoriaFalacias y pifiasObservaciones finalesPerspectivahistrica y referenciasEjercicios 27. de computadores1La tecnologa de computadores ha progresado increblemente en los ltimoscincuenta aos. En 1945, no haba computadores de programa almacenado.Hoy, con unos pocos miles de dlares se puede comprar un computador per-sonal con ms prestaciones, ms memoria principal y ms memoria de discoque un computador que, en 1965,costaba un milln de dlares. Este rpidocrecimiento en las prestaciones es consecuencia de los avances en la tecnolo-ga utilizada en la construccin de computadores y de las innovacionesen losdiseos de los mismos. El aumento del rendimiento de las mquinas se indicaen la Figura 1.1. Mientras que las mejoras tecnolgicas han sido bastanteconstantes, el progreso en la obtencin de mejores arquitecturas ha sido mu-cho menos consistente.Durante los veinticinco primeros aos de los compu-tadores electrnicos, ambas fuerzas contribuan de forma importante; perodurante los veinte ltimos aos, los diseadoresde computadores han depen-dido enormemente de la tecnologa de circuitosintegrados. El crecimiento delrendimiento durante este perodo vana del 18 al 35 por 100por ao, depen-diendo de la clase de computador.Entre todas las lneas de computadores, la velocidad de crecimiento de losgrandescomputadores (mainframes)es la que ms se debe a la tecnologa -lamayora de las innovaciones en organizacin y arquitectura se introdujeronen estas mquinas hace muchos aos. Los supercomputadores han crecidogracias a las mejoras tecnolgicas y arquitectnicas (ver Cap. 7). Los avancesen minicomputadores han incluido formas innovadoras de implementar .ar-quitecturas, as como la adopcin de muchas de las tcnicas de los grandesFundamentos del diseiio 28. 4 ARQUITECTURA DE COMPUTADOREScomputadores. El crecimiento del rendimiento de los microcomputadores hasido el ms rpido, en cierto modo porque estas mquinas aprovecharon lasventajas que ofrece la tecnologa de circuitos integrados. Adems, desde 1980,la tecnologa de microprocesadores ha sido la tecnologa elegida para las nue-vas arquitecturas y las nuevas implementaciones de arquitecturas antiguas.Dos cambios significativosen el mercado de computadores han hecho msfcil que antes el xito comercial de las nuevas arquitecturas. En primer lugar,la eliminacin virtual de la programacin en lenguaje ensamblador ha redu-cido drsticamente la necesidad de la compatibilidad del cdigo objeto. En se-gundo lugar, la creacin de sistemas operativos estandarizados, independien-tes de los vendedores, como por ejemplo UNIX, ha reducido el coste y riesgode lanzar al mercado una nueva arquitectura. Por consiguiente ha habido un1o0RendimientoFIGURA 1.1 Crecimiento del rendimiento a lo largo de los ltimos aiios delas diferentes clases de computadores. El eje vertical muestra el rendimiento re-lativo y el horizontalel ao de introduccin. Las clases de computadores estn de-finidas, bsicamente por su coste. Los supercomputadores son los ms caros-desde, aproximadamente, un milln a decenas de millones de dlares. Disea-dos principalmentepara aplicaciones cientficas, son las mquinas de ms alto ren-dimiento. Los computadores grandes(mainframes)son mquinasde propsito ge-neral de altas prestaciones, normalmentecuestan ms de medio milln de dlaresy, como mximo, unos pocos millones de dlares. Los minicomputadoresson m-quinas de tamao medio que cuestan entre cincuenta mil dlares y diez veces esacantidad. Finalmente, los microcomputadores varan desde los pequeos compu-tadores personales que cuestan unos pocos miles de dlares a las grandes y po-tentes estacionesde trabajo que cuestancincuentamil o ms dlares. La velocidadde crecimiento en el rendimiento de los supercomputadores, minicomputadores yordenadores grandes ha sido del 20 por 100 por ailo, mientras que la velocidad decrecimiento en el rendimiento para los microprocesadores ha sido, aproximada-mente, del 35 por 100 por ao. 29. FUNDAMENTOS DEL DISEO DE COMPUTADORES 5renacimiento en el diseo de computadores: hay muchas nuevas compaastrabajando en nuevas direcciones arquitectnicas, con las nuevas familias decomputadores que emergen -mini-supercomputadores, microprocesadoresdealto rendimiento, supercomputadores grficos y un amplio rango de multi-procesadores- a mayor velocidad que nunca.Comenzando en 1985, la industria de computadores vio un nuevo estilode arquitectura aprovechando esta oportunidad e iniciando un periodo en elcual el rendimiento ha aumentado a una velocidad mucho ms rpida. Al au-nar los avances en la tecnologa de circuitos integrados, las mejoras en la tec-nologa de compiladores y las nuevas ideas arquitectnicas, los diseadorespudieron crear una serie de mquinas que mejoraban el rendimiento, en unfactor de casi 2, cada ao. Estas ideas estn ahora proporcionando una de lasmejorasen rendimiento ms significativamentesostenidas en los ltimos veinteaos. Esta mejora ha sido posible al haber tenido en cuenta una serie de im-portantes avances tecnolgicosjunto a un mejor conocimiento emprico so-bre la utilizacin de los computadores. De esta fusin ha emergido un estilode diseno de computadores basado en datos empricos, experimentacin y si-mulacin. Este estilo y aproximacin al diseo de computadores se reflejaren este texto.Continuar las mejoras en costo y rendimiento de los ltimos veinticinco acincuenta aos requirir innovaciones continuas en el diseo de computado-res, y los autores piensan que las innovaciones estarn basadas en esta apro-ximacin cuantitativa de la arquitectura de computadores. Por consiguiente,este libro se ha escrito no slo para documentar este estilo de diseno, sinotambin para estimular a que el lector contribuya en este campo.7 )Definicionesde rendimientoPara familiarizar al lector con la terminologa y conceptos de este libro, estecaptulo introduce algunos trminos e ideas clave. Ejemplos de las ideas men-cionadas aqu aparecen a lo largo del libro, y algunas de ellas -segmentacin(pipelining),jerarqua de memoria, rendimiento de la CPU y medida de cos-tes- son el ncleo de captulos completos. Comencemos con definiciones derendimiento relativo.Cuando se dice que un computador es ms rpido que otro, qu quere-mos significar? El usuario delcomputador puede decir que un computador esms rpido cuando ejecuta un programa en menos tiempo, mientras que eldirector de un centro de clculo puede decir que un computador es ms r-pido cuando completa ms tareas en una hora. El usuario del computador estinteresado en reducir el tiempo de respuesta-el tiempo transcunido entre elcomienzo y el final de un evento- denominado tambin tiempo de ejecucino latencia. El director del centro de clculo est interesado en incrementar laproductividad (throughput) -la cantidad total de trabajo realizado en untiempo determinado- a veces denominado ancho de banda. Normalmente,los trminos tiempo de respuesta, tiempo de ejecucin y productividadse utilizan cuando se est desarrollando una tarea de clculo completa. Lostrminos elatencim y ancho de banda casi siempre se eligen cuando se ha- 30. bla de un sistema de memoria. Todos estos trminos aparecern a lo largo deeste texto.Las siguientesmejoras en rendimiento incrementan la productividad, hacendisminuir el tiempo de respuesta, o ambas cosas?1. Ciclo de reloj ms rpido.l 2. Mltiples procesadores para tareas separadas(tratamiento del sistema dereservas de una compaa area, para un pas, por ejemplo).3. Procesamientoparalelo de problemas cientficos.La disminucin del tiempo de respuesta, habitualmente, mejora la producti-vidad. Por consiguiente, 1 y 3 mejoran el tiempo de respuesta y la produc-tividad. En 2, ninguna tarea funciona ms rpida, por tanto, slo incrementala productividad.A veces estas medidas se describen mejor con distribucionesde probabili-dad en lugar de con valores constantes. Por ejemplo, consideremosel tiempode respuesta para completar una operacin de E/S en un disco. El tiempo derespuesta depende de una serie de factores no determinsticos,como lo que eldisco est haciendo en el instante de la peticin de E/S y del nmero de tareasque estn esperando acceder al disco. Debido a que estos valores no son fijos,tiene ms sentido hablar de tiempo medio de respuesta de un acceso al disco.De igual forma, la productividad efectiva del disco -el nmero de datos querealmente va o viene del disco por unidad de tiempo- no es un valor cons-tante. En la mayor parte de este texto, trataremos el tiempo de respuesta y laproductividad como valores determinsticos, aunque esto cambiar en elCaptulo 9, cuando hablemos de E/S.Cuando se comparan alternativasde diseo, con frecuencia, queremos re-lacionar el rendimiento de dos mquinas diferentes, por ejemplo X e Y. Lafrase X es ms rpida que Y se utiliza aqu para significarque el tiempo derespuesta o tiempo de ejecucin es inferior en X que en Y para una tarea dada.En particular, X es n por 100ms rpido que Y significaTiempo de ejecuciny n= 1 +-Tiempo de ejecucinx 1O0Como el tiempo de ejecucin es el recproco del rendimiento, se mantiene lasiguiente relacin:1n Tiempo de ejecuciny Rendimientoy Rendimientox1 + - = -- --100 Tiempo de ejecucinx 1 RendimientoyRendimientox 31. FUNDAMENTOS DEL DISENO DE COMPUTADORES 7Algunas personas consideran un incremento en el rendimiento, n, como la di-ferencia entre el rendimiento de la mquina ms rpida y la ms lenta, divi-dido por el rendimiento de la mquina ms lenta. Esta definicin de n esexactamenteequivalente a nuestra primera definicin, como podemos ver:n Rendimientox Tiempo de ejecuciny1 +- -- --100 Rendimientoy Tiempo de ejecucinxLa frase la productividad de X es el 30 por 100 superior que la de Ysignifica que el nmero de tareas completadas por unidad de tiempo en lamquina X es 1,3veces el nmero de tareas completadasen la mquina Y.Si la mquina A ejecuta un programa en diez segundosy la mquina B eje-cuta el mismo programa en quince segundos, cul de las siguientes senten-cias es verdadera?iA es el 50 por 100 ms rpida que B.iA es el 33 por 100 ms rpida que B.Tiempo de ejecucinB n= 1 + -Tiempo de ejecucin, 1O0RespuestaTiempo de ejecucinB- Tiempo de ejecucin,n = 100Tiempo de ejecucin,Que la mquina A sea el n por 100ms rpida que la mquina B puede ex-presarse como1 A es, por tanto, el 50 por 100 ms rpida que B.Para ayudar a prevenir malentendidos-y debido a la faltade definicionesconsistentes para ms rpido que y ms lento que- nunca utilizaremosla frase ms lento que en una comparacin cuantitativa de rendimiento. 32. Como rendimiento y tiempo de ejecucin son recprocos, incrementar elrendimiento hace decrecer el tiempo de ejecucin. Para ayudar a evitar con-fusiones entre los trminos eincrementam y decrementan>,habitualmente,diremos mejorar el rendimiento o mejorar el tiempo de ejecucin cuandoqueramos significar incremento de rendimiento y disminucin de tiempo deejecucin.Productividad y latencia interactan de forma diferente en los diseos decomputadores. Una de las interacciones ms importantes se presenta en lasegmentacin (pipelining).La segmentacin es una tcnica de implementa-cin que mejora la productividad al solapar la ejecucin de mltiples instruc-ciones; la segmentacin se explica con detalle en el Captulo 6. La segmenta-cin de instruccioneses anloga a utilizar una lnea de ensamblajepara fabricarcoches. En una lnea de ensamblaje, se pueden tardar ocho horas en construirun coche completo, pero si hay ocho pasos en la lnea de ensamblaje, cadahora se fabrica un nuevo coche. En la lnea de ensamblaje, no se ve afectadala latencia para construir un coche, pero la productividad aumenta proporcio-nalmente con el nmero de etapas de la lnea, si todas las etapas son de lamisma duracin. El hecho de que la segmentacin en los computadores ten-ga algn gasto por etapa incrementa la latencia en cierta cantidad para cadaetapa del cauce.7.3Principioscuantitativos del dise60de computadoresEsta seccin introduce algunas reglas y observaciones importantes para dise-ar computadores.Acelerar el caso comnQuiz el principio ms importante y generalizadodel diseo de computadoressea acelerar el caso comn: al realizar un diseo, favorecer el caso frecuentesobre el infrecuente. Este principio tambin se aplica cuando se determinacmo emplear recursos, ya que el impacto de hacer alguna ocurrencia ms r-pida es mucho mayor si la ocurrencia es frecuente. Mejorar el evento fre-cuente en lugar del evento raro, evidentemente, tambin ayudar a aumentarel rendimiento. Adems, el caso frecuente es, a menudo, ms simple y puederealizarse de forma ms rpida que el caso infrecuente. Por ejemplo, cuandosumamos dos nmeros en la unidad central de proceso (CPU), podemos es-perar que el desbordamiento (overflow) sea una circunstancia infrecuente y,por tanto, podemos mejorar el rendimiento optimizando el caso ms comnde ausencia de desbordamiento. Este hecho puede ralentizar la situacin en laque se presente un desbordamiento, pero si este caso es infrecuente, el rendi-miento global mejorar al optimizar el caso normal.Veremos muchos casos de este principio a lo largo de este texto. Al aplicareste sencillo principio, hemos de decidir cul es el caso frecuente y cmo sepuede mejorar el rendimiento haciendo este caso ms rpido. Una ley fun- 33. FUNDAMENTOS DEL DISENO DE COMPUTADORES 9damental, denominada Ley de Amdahl, puede utilizarse para cuantificar esteprincipio.Ley de AmdahlEl aumento de rendimiento que puede obtenerse al mejorar alguna parte deun computador puede calcularse utilizando la Ley de Amdahl. La Ley deAm-dahl establece que la mejora obtenida en el rendimiento al utilizar algn modode ejecucin ms rpido est limitada por la fraccin de tiempo que se puedautilizar ese modo ms rpido.La Ley de Amdahl define la ganancia de rendimiento o aceleracin (spee-dup) que puede lograrse al utilizar una caracterstica particular. Qu es laaceleracin? Supongamosque podemos hacer una mejora en una mquina quecuando se utilice aumente su rendimiento. La aceleracin (speedup)es la re-lacinAceleracinde rendimiento =- Rendimientode la tarea completautilizando la mejora cuando sea posible-Rendimientode la tarea completasin utilizar la mejoraAlternativamente:Aceleracin de rendimiento =- Tiempode ejecucin de la tarea sin utilizar la mejora-Tiempode ejecucin de la tarea completautilizando la mejora cuando sea posibleLa aceleracin nos indica la rapidez con que se realizar una tarea utilizandouna mquina con la mejora con respecto a la mquina original.Considerar el problema de viajar desde Nevada a California a travs de lasmontaas de Sierra Nevada y del desierto de Los Angeles. Hay disponibles va-rios tipos de vehculos, pero, desgraciadamente, el viaje se realiza a travs dereas ecolgicamente sensibles por las montaas que hay que atravesar. Seemplean veinte horas en recorrer a pie las montaas. Sin embargo, existe laposibilidad de recorrer las ltimas 200 millas en un vehculo de alta veloci-dad. Hay cinco formas de completar la segunda parte del viaje:1. Ir a pie a una velocidad media de 4 millas por hora.2. Montar en bicicleta a una velocidad media de 10millas por hora.3. Conducir un ~HyundaiExceln en el cual la velocidad media es de 50 millaspor hora.4. Conducir un ~FerrariTestarossa~en el cual la velocidad media es de120millas por hora. 34. 10 ARQUITECTURA DE COMPUTADORESRespuesta5. Conducir un vehculo oruga en el cual la velocidad media es de 600 millaspor hora.Cunto se tardar en realizar el viaje completo utilizando estos vehculos,y cul es el aumento de velocidad si se toma como referencia el recomdo apie de la distancia completa?Podemos encontrar la solucin determinando cunto durar la segundaparte del viaje y sumando ese tiempo a las veinte horas necesariaspara cruzarlas montaas. La Figura 1.2 muestra la efectividadde utilizar los diversosmo-dos, mejorados, de transporte.La Ley de Amdahl nos da una forma rpida de calcular la aceleracin, quedepende de dos factores:1. La fraccin del tiempo de clculo de la mquina original que pueda uti-lizarse para aprovechar la mejora. En el ejemplo anterior la fraccin es50- Este valor, que llamaremos Fra~cin,~,,,~,, es siempre menor o igual70 que l.2. La optimizacin lograda por el modo de ejecucin mejorado; es decir,cunto ms rpido con la que se ejecutara la tarea si solamente se utili-zase el modo mejorado. En el ejemplo anterior este valor aparece en lacolumna etiquetada aceleracin en el desierto. Este valor es el tiempodel modo original con respecto al tiempo del modo mejorado y es siem-pre mayor que 1. Llamaremos a este valor A~eleracin,,,,~,.El tiempo de ejecucin utilizando la mquina original con el modo mejoradoser el tiempo empleado utilizando la parte no mejorada de la mquina msel tiempo empleado utilizando la parte mejorada.Vehculo para la segunda Horas de la Aceleracin en el Horas del viaje Aceleracin en elparte del viajesegunda parte desiertocompleto viaje completodel viajeA pie 50,OO 1,o 70,OO 1,oBicicleta 20,OO 2 3 40,OO 1,8Excel 4,OO 12,5 24,OO 2,9Testarossa 1,67 30,O 21,67 3,2I Vehculo oruga 0,33 150,O 20,33 3,4 1FIGURA 1.2 Las relaciones de aceleracin obtenidas para los diferentes medios de transporte dependefuertemente de que hay que cruzar a pie las montaas. La aceleracin en el desierto -una vez que se hanatravesado las montatias- es igual a la velocidad utilizando el vehculo designado dividido por la velocidad apie; la columna final muestra la rapidez del viaje completo cuando se compara con el viaje a pie. 35. FUNDAMENTOS DEL DISENO DE COMPUTADORES 11Tiempo de e j e c u ~ i n ~ ~ ~ , ~= Tiempo de ejecucinantiguoLa aceleracin global es la relacin de los tiempos de ejecucin:Tiempo de ejecucinantiguoAceleracinglobal= --Tiempo de e j e c u ~ i n ~ ~ ~ , ~Suponer que estamos considerando una mejora que corra diez veces ms r-Ejemplo pida que la mquina original, pero slo es utilizable el 40 por 100del tiempo.1Cul es la aceleracin global lograda al incorporar la mejora?RespuestaLa Ley de Amdahl expresa la ley de rendimientos decrecientes: la mejoraincremental en la aceleracin conseguida por una mejora adicional en el ren-dimiento de una parte del clculo disminuye tal como se van aadiendo me-joras. Un corolarioimportante de la Ley de Amdahl es que si una mejora sloes utilizable por una fraccin de una tarea, no podemos aumentar la veloci-dad de la tarea ms que el recproco de 1 menos esa fraccin.Un error comn al aplicar la Ley de Amdahl es confundir fraccin detiempo convertido para utilizar una mejora y fraccin de tiempo despusde que se utiliza la mejora. Si, en lugar de medir el tiempo que podna utili-zar la mejora en un clculo, midisemos el tiempo despus que se ha utilizadola mejora, los resultados seran incorrectos. (Intentar el Ejercicio 1.8 paracuantificar el error.)La Ley de Amdahl puede servir como gua para ver cmo una mejora au-menta el rendimiento y cmo distribuir los recursos para mejorar la relacincoste/rendimiento. El objetivo, claramente, es emplear recursos de forma pro-porcional al tiempo que se requiere en cada parte. 36. 12 ARQUITECTURA DE COMPUTADORESEjemploSupongamos que se quiere mejorar la velocidad de la CPU de nuestra m-quina en un factor de cinco (sin afectar al rendimiento de E/S) por cinco ve-ces el coste. Supongamos tambin que la CPU se utiliza el 50 por 100 deltiempo, y que el tiempo restante la CPU est esperando las E/S. Si la CPUsupone un tercio del coste total del computador, jel incremento de la veloci-dad de la CPU en un factor de cinco es una buena inversin desde un puntode vista coste/rendimiento?La aceleracin obtenida esAceleracin =1 --1-= 1,670,5 0,60,5 + -5La nueva mquina costana2 1- 1 + - . 5 = 2,33 veces la mquina original33IComo el incremento de coste es mayor que la mejora de rendimiento, estecambio no mejora la relacin coste/rendimiento.Localidad de referenciaAunque la Ley de Amdahl es un teorema que se aplica a cualquier sistema,otras observaciones importantes provienen de las propiedades de los progra-mas. La propiedad ms importante, que regularmente explotamos de un pro-grama, es la localidad de referencia:los programas tienden a reutilizar los da-tos e instrucciones que han utilizado recientemente. Una regla emprica, muycorroborada, es que un programa emplea el 90 por 100 de su tiempo de eje-cucin en slo el 10 por 100 del cdigo. Una implicacin de la localidad esque, basndose en el pasado reciente del programa, se puede predecir con unaprecisin razonable qu instrucciones y datos utilizar un programa en el fu-turo prximo.Para examinar la localidad, se midieron algunos programas para determi-nar qu porcentaje de las instrucciones eran responsablesdel 80 y 90 por 100de las instrucciones ejecutadas. Los datos se muestran en la Figura 1.3, y losprogramas se describen con detalle en el captulo siguiente.La localidad de referenciatambin se aplica a los accesos a los datos, aun-que no tan fuertemente como a los accesos al cdigo. Se han observado dostipos diferentes de localidad. La localidad temporal especfica que los elemen-tos accedidos recientemente, probablemente, sern accedidos en un futuroprximo. La Figura 1.3 muestra un efecto de la localidad temporal. La loca-lidad espacial establece que los elementos cuyas direcciones son prximastienden a ser referenciadosjuntos en el tiempo. Veremos estos principios apli-cados ms tarde en este captulo, y ampliamente en el Captulo 8. 37. Itodas lasreferencias180 % detodas lasreferenciasGCC Spice TeXFIGURA 1.3 Este dibujo muestra el porcentaje de las instrucciones que sonresponsables del 80 y 90 por 100 de las ejecuciones de instrucciones. Porejemplo, menos del 4 por 100 de las instrucciones del programa Spike (llamadastambin instrucciones estticas) representanel 80 por 100 de las instruccionesdi-nmicamente ejecutadas, mientras que menos del 10 por 100 de las instruccionesestticas contabilizan el 90 por 100 de las instrucciones ejecutadas. Menos de lamitad de las instrucciones estticas se ejecutanal menos una vez en cualquier eje-cucin -en Spice slo el 30 por 100 de las instrucciones se ejecutan una o msveces. Descripciones detalladas de los programas y sus entradas se dan en laFigura 2.17 (pg. 71).1m 4 1 El trabajo de un disefiador de computadoresUn arquitecto de computadores disea mquinas para ejecutar programas. Latarea de disear un computador presenta muchos aspectos, entre los que seincluyen el diseo del repertorio de instrucciones, la organizacin funcional,el diseo lgico y la implementacin. La implementacin puede abarcar el di-seo de circuitos integrados (IC), encapsulamiento, potencia y disipacin tr-mica. Habna que optimizar el diseo de la mquina en estos niveles. Esta op-timizacin requiere estar familiarizado con un amplio rango de tecnologas,desde los compiladores y sistemas operativos al diseo lgico y encapsula-miento.Algunas personas utilizan el trmino arquitectura de computadores paradenominar solamente el diseo del repertorio de instrucciones. Los dems as-pectos del diseo los referencian como implementacin, insinuando, confrecuencia, que la implementacin no es interesante o es menos estimulante. 38. 14 ARQUITECTURA DE COMPUTADORESLos autores piensan que este punto de vista, adems de ser incorrecto, es tam-bin responsable de los errores que se cometen en el diseo de nuevos reper-torios de instrucciones.El trabajo del arquitecto o diseador va mucho msall del diseo del repertorio de instrucciones, y los obstculos tcnicos quesurgen en otros aspectos del proyecto son ciertamente tan sugestivoscomo losque se encuentran al realizar el diseo del repertorio de instrucciones.En este libro el trmino arquitecturaa nivel lenguaje mquina se refiere alrepertoriode instruccionesconcreto, visibles por el programador. La arquitec-tura a nivel lenguaje mquina sirve como frontera entre software y ahard-ware, y ese tema es el foco de los Captulo 3 y 4. La implementacin de unamquina tiene dos componentes: organizacin y hardware. El trmino or-ganizacin incluye los aspectos de alto nivel del diseo de un computador, talcomo sistema de memoria, estructura del bus y diseointerno de la CPU. Porejemplo, dos mquinas con la misma arquitectura a nivel lenguaje mquina,pero con organizaciones diferentes, son la VAX-11/780 y la VAX 8600. El tr-mino Hardware se utiliza para referenciar las cosas especficas de una m-quina. Esto incluye el diseo lgico detallado y la tecnologa de encapsula-miento de la mquina. Este libro hace nfasisen la arquitecturaa nivel lenguajemquina y en la organizacin. Dos mquinas, con idnticas arquitecturas anivel lenguaje mquina y organizaciones casi idnticas, que se diferencianprincipalmente a nivel hardware, son la VAX-111780 y la 111785; la 111785utiliz una tecnologa de circuitos integradosmejorada para conseguir mayorfrecuencia de reloj y presentaba pequeos cambiosen el sistema de memoria.En este libro la palabra arquitectura est pensada para cubrir los tres aspec-tos del diseo de un computador.RequerimientosfuncionalesLos arquitectos de computadores deben disear un computador que cumplaciertos requerimientos funcionales con determinadas ligaduras de precio yrendimiento; con frecuencia, tambin tienen que determinar los requerimien-tos funcionales y, en este caso, puede ser una tarea de gran magnitud. Los re-querimientos pueden ser caractersticas especficas,inspiradaspor el mercado.El software de aplicaciones conduce, con frecuencia, a la eleccin de ciertosrequerimientos funcionales, al determinar cmo se utilizar la mquina. Siexisteun gran cuerpo de softwarepara cierta arquitectura a nivel lenguaje m-quina, el arquitecto puede decidir que una nueva mquina implemente un re-pertorio de instruccionesya existente. La presencia de un gran mercado, parauna clase particular de aplicaciones, podra estimular a los diseadores a in-corporar requerirnientosque hagan a la mquina competitivaen ese mercado.La Figura 1.4 (vr pg. 15)resume algunos de los requerimientos que son ne-cesariostener en cuenta a la hora de disear una nueva mquina. Muchos deestos requerimientosy caractersticasse examinarn en profundidad en los ca-ptulos siguientes.Muchos de los requerimientosde la Figura 1.4 representan un mnimo ni-vel de soporte. Por ejemplo, los sistemas operativos modernos utilizan me-moria virtual y proteccin de memoria. Este requerimiento establece un m-nimo nivel de soporte, sin el cual la mquina no sera viable. Cualquier 39. FUNDAMENTOS DEL DISEO DE COMPUTADORES 15-Requerimientos funcionales- -- -Caractersticas tpicas requeridas o soportadasArea de aplicacin Objetivo-delcomputador.Prposito especial Rendimiento ms alto para aplicacionesespecficas (Cap. 10).Propsito general Rendimiento equilibrado para un rango de tareas.Cientfica Punto flotante de alto rendimiento (ApndiceA).Comercial Soporte para COBOL (aritmtica decimal), soporte para bases dedatos y tratamiento de transacciones.Nivel de compatibilidad software Determina la cantidad de software existente para la mquina(Cap. 10).En lenguajede programacin Ms flexible para el diseador, necesita nuevo compilador.Cdigo objeto o binario compatible La arquitectura est completamente definida -poca flexibili-dad-, pero no necesita inversin en software ni en portar pro-gramas.Requerimientos del sistema operativo (SO) Caractensticas necesariaspara soportar el SO escogido.Tamao del espacio de direcciones Caracterstica muy importante (Cap. 8); puede limitar aplicacio-nes.Gestin de memoria Requerida para SO modernos; puede ser plana, paginada, seg-mentada (Cap. 8).Proteccin Diferentes SO y necesidadesde aplicacin: proteccin de pginasfrente a proteccin de segmentos (Cap. 8).Cambio de contexto Requerido para interrumpir y recomenzar un programa; el rendi-miento vana (Cap. 5).Interrupciones y traps Tipos de soporte impactan sobre el diseo hardwarey SO (Cap. 5).Estndares Ciertos estndares pueden ser requeridos por el mercado.Punto flotante Formato y aritmtica: IEEE, DEC, IBM (ApndiceA).Bus de E/S Para dispositivosde E/S: VME, SCSI; NuBus, Futurebus (Cap. 9).Sistemasoperativos UNIX, DOS o patente del vendedor.Redes Soporte requerido para distintas redes: Ethernet, FDDI (Cap. 9).Lenguajesde programacin Lenguajes(ANSI C, FORTRAN 77, ANSI COBOL)afectan al re-pertorio de instrucciones.FIGURA 1.4 Resumen de algunos de los requerimientos funcionales ms importantes con que se en-frenta un arquitecto. La columna de la izquierda describe la clase de requerimiento, mientras que la columnade la derecha da ejemplos de caractersticas especficas que pueden ser necesarias. Examinaremos estos re-querimientosde diseo con ms detalle en captulos posteriores. 40. hardware adicional por encima de tales mnimos puede ser evaluado desde elpunto de vista del coste/rendimiento.La mayora de los atributos de un computador -soporte hardware paradiferentes tipos de datos, rendimiento de diferentes funciones, etc.- puedenser evaluados en base al coste/rendimiento para el mercado pensado. La si-guiente seccin explica cmo deben tenerse en cuenta estas cuestiones.Equilibrar software y hardwareUna vez que se ha establecido un conjunto de requerimientos funcionales, elarquitecto debe intentar de optimizar el diseo. Que el diseo elegido sea p-timo, depende, por supuesto, de la mtrica elegida. Las mtricas ms comu-nes involucran coste y rendimiento. Dado algn dominio de aplicaciones, sepuede intentar cuantificar el rendimiento de la mquina por un conjunto deprogramas que se escogen para representar ese dominio de aplicaciones. (Ve-remos cmo medir el rendimiento y qu aspectos afectan al coste y precio enel siguiente captulo.) Otros requerimientos medibles pueden ser importantesen algunos mercados; la fiabilidad y tolerancia a fallos son, con frecuencia,cruciales en los entornos de tratamiento de transacciones.A lo largo de este texto haremos nfasis en la optimizacin de coste/ren-dimiento de la mquina. Esta optimizacin es, en gran parte, una respuesta ala pregunta de jcmo se implementa mejor una funcionalidad requerida? Lasimplementaciones hardware y software de una determinada caracterstica tie-nen diferentes ventajas. Las ventajas principales de una implementacin soft-ware son el bajo coste de los errores, ms fcil diseo, y actualizacin mssimple. El hardware ofrece el rendimiento como una nica ventaja, aunquelas implementaciones hardware no son siempre ms rpidas -un algoritmosuperior en software puede superar un algoritmo inferior implementado enhardware. El equilibrio entre hardware y software nos llevar a la mejor m-quina para las aplicaciones de inters.A veces, un requerimiento especficopuede necesitar, efectivamente, la in-clusin de soporte hardware. Por ejemplo, una mquina que vaya a ejecutaraplicacionescientficascon clculosintensivos en punto flotante necesitar contoda seguridad hardware para las operaciones en punto flotante. Esto no esuna cuestin de funcionalidad, sino de rendimiento. Podra utilizarse softwarebasado en punto flotante, pero es tan lento que esa mquina no sera compe-titiva. El punto flotante soportado en hardware es, de hecho, el requerimientopara el mercado cientfico. Por comparacin, considrese la construccin deuna mquina para soportar aplicaciones comerciales escritas en COBOL. Ta-les aplicaciones utilizan frecuentemente operaciones con decimales y cadenas;por tanto, muchas arquitecturas han incluido instrucciones para estas funcio-nes. Otras mquinas han soportado estas funciones utilizando una combina-cin de software y operaciones sobre enteros y lgicas estndares. Esto esun ejemplo clsico de un compromiso entre implementacin hardware y soft-ware, y no hay una solucin nica correcta.Al elegir entre dos diseos, un factor que un arquitecto debe considerar esel de su complejidad. Los diseos complejos necesitan ms tiempo de reali-zacin, prolongando el tiempo de aparicin en el mercado. Esto significa que 41. FUNDAMENTOS DEL DISENO DE COMPUTADORES 17un diseo que emplee ms tiempo necesitar tener mayor rendimiento paraque sea competitivo. En general, es ms fcil tratar con la complejidad ensoftware que en hardware, sobre todo porque es ms fcil depurar y cambiarel software. Por eso, los diseadores pueden tratar de desplazar la funcionali-dad del hardware al software. Por otra parte, las decisionesen el diseo de laarquitectura a nivel lenguaje mquina y en la organizacin pueden afectar ala complejidad de la implementacin as como a la complejidad de los com-piladores y sistemas operativos de la mquina. El arquitecto siempre debe serconsciente del impacto que el diseo que elija tendr sobre el tiempo de di-seo del hardware y del software.Disear para perdurar a nuevas tendenciasSi una arquitectura ha de tener xito, debe ser diseada para que sobreviva alos cambios en la tecnologa hardware, tecnologa software y aplicacionesca-ractersticas. El diseador debe ser consciente, especialmente de las tendenciasen la utilizacin del computador y de la tecnologa de los computadores. Des-pus de todo, una nueva arquitectura a nivel lenguaje mquina que tenga xitopuede durar decenasde aos -el ncleo de la IBM 360 ha sido utilizado desde1964. El arquitecto debe planificar para que los cambios tecnolgicospuedanincrementar con xito la vida de una mquina.Para planificar la evolucin de una mquina, el diseador debe ser espe-cialmente consciente de los rpidos cambios que experimentan las tecnologasde implementacin. La Figura 1.5 muestra algunas de las tendencias ms im-portantes en las tecnologas del hardware. Al escribir este libro, el nfasis esten los principios de diseo que pueden ser aplicados con las nuevas tecnolo-gas y considerando las futuras tendencias tecnolgicas.Estos cambios tecnolgicos no son continuos sino que, con frecuencia, sepresentan en pasos discretos. Por ejemplo, los tamaos de las DRAM (me-moria dinmica de acceso aleatorio) aumentan siempre en factores de 4, de-bido a la estructura bsica de diseo. Entonces, en lugar de duplicarse cadauno o dos aos, la tecnologa DRAM se cuadruplica cada tres o cuatro aos.Estos cambios en la tecnologa llevan a situaciones que pueden habilitar unatcnica de implementacin que, anteriormente, era imposible. Por ejemplo,cuando la tecnologa MOS logr ubicar entre 25 000 y 50 000 transistores enun nico circuito integrado, fue posible construir un microprocesador de32 bits en una sola pastilla integrada. Al eliminar los cruces entre chips dentrode la CPU, fue posible un enorme incremento en el coste/rendimiento. Estediseo era sencillamente impensable hasta que la tecnologa alcanz un ciertogrado. Estos umbrales en la tecnologa no son raros y tienen un impacto sig-nificativo en una amplia variedad de decisiones de diseo.El arquitecto tambin necesitar estar al corriente de las tendencias ensoftware y de cmo los programas utilizarn la mquina. Una de las tenden-cias software ms importantes es la creciente cantidad de memoria utilizadapor los programas y sus datos. La cantidad de memoria necesaria por el pro-grama medio ha crecido en un factor de 1,5 a 2 por ao. Esto se traduce enun consumo de bits de direcciones a una frecuencia de 112 bit a 1 bit por ao.Subestimar el crecimiento del espacio de direcciones es, con frecuencia, la ra- 42. 18 ARQUITECTURA DE COMPUTADORESTecnologa Tendenciasde rendimientoy densidadTecnologia de CI lgicos El nmero de transistores en un chip aumenta apro-ximadamente el 25 por 100por ao, duplicndoseen tres aos. La velocidad de los dispositivos au-menta casi a esa rapidez.:---------DRAM semiconductora La densidad aumenta en un 60 por 100por aiio, cua-druplicndose en tres aos. La duracin del cicloha mejorado muy lentamente, decreciendo apro-ximadamente una tercera parte en diez aos.Tecnologa de disco La densidad aumenta aproximadamente el 25 por100 por ano, duplicndose en tre aos. El tiempode acceso ha mejorado un tercio en diez aos.FIGURA 1.5 Las tendencias en las tecnologas de implementacin de loscomputadores muestran los rpidos cambios con que los diseadores debenenfrentarse. Estos cambios pueden tener un impacto dramtico sobre los dise-adores cuando afectan a decisiones a largo plazo, como la arquitectura a nivel len-guaje mquina. El coste por transistor para la 16gica y el coste por bit para la me-moria de disco o de semiconductores disminuye muy prximamente a la velocidada la cual aumenta la densidad. Las tendencias en los costes se consideran con msdetalle en el captulo siguiente. En el pasado, la tecnologa de las DRAM (memoriadinmica de acceso aleatorio) ha mejorado ms rpidamente que la tecnologa dela 16gica. Esta diferencia es debida a las reducciones en el nmero de transistorespor celda DRAM y a la creacin de tecnologa especializada para las DRAM. Comola mejora de estas fuentes disminuya, la densidad creciente en la tecnologa de lalgica y en la de memorias llegarn a ser comparables.zn principal por la que una arquitectura a nivel lenguaje mquina debe serabandonada. (Para una discusin posterior, ver el Captulo 8 sobre jerarquade memoria.)Otra tendencia software importante en los ltimos veinte aos, ha sido lasustitucin del lenguaje ensamblador por los lenguajes de alto nivel. Esta ten-dencia ha jugado un papel importante para los compiladores y en el redirec-cionamiento de arquitecturas hacia el soporte del compilador. La tecnologade compiladores ha ido mejorando uniformemente. Un diseador debe com-prender esta tecnologa y la direccin en la cual est evolucionando, ya quelos compiladores se han convertido en la interfaz principal entre el usuario yla mquina. Hablaremos de los efectosde la tecnologa de compiladores en elCaptulo 3.Un cambio fundamental en la forma de programar puede demandar cam-bios en una arquitectura para soportar, eficientemente, el modelo de progra-macin. Pero la emergencia de nuevos modelos de programacin se presentaa una velocidad mucho ms lenta que las mejoras en la tecnologa de compi-ladores: en oposicin a los compiladores, que mejoran anualmente, los cam-bios significativos en los lenguajesde programacin se presentan una vez pordcada. 43. Cuando un arquitecto ha comprendido el impacto de las tendencias hard-ware y softwareen el diseo de la mquina, entonces puede considerar la pre-gunta de cmo equilibrar la mquina. Cunta memoria es necesario planifi-car para conseguirla velocidad elegida de la CPU? Cuntas E/S se necesitarn?Para intentar dar alguna idea de cmo constituir una mquina equilibrada,Case y Amdahl acuaron dos reglas empricas que, habitualmente, se utilizanjuntas. La regla establece que una mquina de 1-MIPS (milln de instruccio-nespor segundo) est equilibrada cuando tiene 1 megabyte de memoria y unaproductividad de E/S de 1 megabit por segundo. Esta regla proporciona unpunto de partida razonable para disear un sistema equilibrado, pero debe serrefinada al medir el rendimiento de la mquina cuando est ejecutando lasaplicaciones pensadas.1=S 1 Juntando todo:el concepto de jerarqua de memoriaEn las seccionesJuntando todo que aparecen casi al final de cada captulo,mostramos ejemplos reales que utilizan los principios expuestos en ese cap-tulo. En este primer captulo, explicamos una idea clave de los sistemas dememoria que ser nuestro nico foco de atencin en el Captulo 8.Para comenzar esta seccin, echemos un vistazo a un simple axioma deldiseo hardware: ms pequeo es ms rpido. Las partes ms pequeas dehardware, generalmente, son ms rpidas que las ms grandes. Este sencilloprincipio es aplicable, particularmente, a las memorias, por dos razones dife-rentes. Primero, en las mquinas de alta velocidad, la propagacin de la seales una causa importante de retardo; las memorias ms grandes tienen ms re-tardo de seal y necesitan ms niveles para decodificar las direcciones. Se-gundo, en muchas tecnologas se pueden obtener memorias ms pequeas, queson ms rpidas que memorias ms grandes. Esto es as, bsicamente, porqueel diseador puede utilizar ms potencia por celda de memoria en un diseoms pequeo. Las memorias ms rpidas estn, generalmente, disponibles ennmeros ms pequeos de bits por chip, en cualquier instante de tiempo, perocon un coste sustancialmente mayor por byte.Incrementar el ancho de banda de la memoria y decrementar la latenciade acceso a memoria son cruciales para el rendimiento del sistema, y muchasde las tcnicas de organizacin que explicamos se enfocarn sobre estas dosmtricas. Cmo podemos mejorar estas dos medidas? La respuesta se en-cuentra al combinar los principios explicadosen este cap