Arquitectura de Computadores. Tema 9. Microprogramación

Transcripción

1 Arquitectura de Computadores Tema 9 Microprogramación Eduardo Daniel Cohen dcohen@arnet.com.ar 1

2 Casos de Mayor complejidad. Qué pasa si hay muchos más estados y condiciones de entradas para determinar el control? El manejo con tablas se hace engorroso. Se recurre a CAD. Y si luego se necesita realizar correcciones? Veremos otra forma de realización del control llamado MICROPROGRAMACION. 2

3 Analicemos la implementación con ROM ROM2 se encarga del próximo estado, le llamemos Secuenciador ROM1 contiene las señales de salida del control, o instrucciones para el control, le llamaremos microinstrucciones. El SECUENCIADOR insume la mayoría de las celdas 4 K en el ejemplo del tamaño total de 4,3 Kbits. En general las secuencias de estados son simples. En muchos casos se pasa a un único estado siguiente (6 al 7, 10 al 11, 3 al 4 en el ejemplo). En casos de saltos múltiples, muchos sólo son bifurcaciones. Esto nos sugiere la posibilidad de implementar el secuenciador en base a un registro que puede cargarse desde varias fuentes. Incrementando en 1 paso al estado siguiente. Cargando de otra fuente realizo un salto.. Las señales de control del secuenciador se consideran salidas de control. 3

4 Unidad de Control con Secuenciador ROM1 Señales de Salida Outputs Al Camino de Datos 1 Adder Inputs Registro de Estado Control de Secuencia Ponga en 0 (Fetch) Saltos Varios... Incremente en 1 Selección de Próx Dirección Opcode 4

5 Repasemos las Secuencias de Estados: Próximo Estado desde el Actual Control de Secuencia Estado 0 Estado1 Incrementar en 1 Estado 1 S2, S6, S8, S9, S10 Según Op-Code DISPATCH ROM1 Estado 2 S3, S5 Según Op-Code DISPATCH ROM2 Estado 3 Estado 4 Incrementar en 1 Estado 4 Estado 0 Ponga 0 Estado 5 Estado 0 Ponga 0 Estado 6 Estado 7 Incrementar en 1 Estado 7 Estado 0 Ponga 0 Estado 8 Estado 0 Ponga 0 Estado 9 Estado 0 Ponga 0 Estado 10 Estado 11 Incrementar en 1 Estado 11 Estado 0 Ponga 0 5

6 Detalle del Control con Secuenciador 1 Adder Address Select Logic Control Logic Inputs State Reg 3 2 Mux 1 0 ROM2 Opcode 0 ROM1 Dispatch ROM 1 Op Name State Rtype jmp beq ori lw sw 0010 Dispatch ROM 2 Op Name State lw sw

7 Contenido de la ROM En lugar de la PLA, usaremos una ROM con una palabra por estado (contiene las salidas de control o microinstrucción ) Tenemos 17 (o más) salidas de control para el camino de datos y 2 para el secuenciador State number Control Word Bits 18-2 Control Word Bits

8 Microprogramación En la ROM se escribe una secuencia de palabras de control, cada una de ellas controla la acción y el pase a la próxima. Un Programa es una secuencia de instrucciones, cada una de ellas dice qué se hace con los datos o con la secuencia (saltos) Análogamente podríamos decir que en la ROM se escribe un microprograma y a cada palabra le llamaremos microinstrucción. Una microinstrucción maneja señales de control. Una Instrucción maneja datos. No confundir. A la instrucción le llamaremos macroinstrucción para no confundir. El registro de estado apunta a la próxima microinstrucción. - Es similar al PC. - Por ello le llamamos µpc. 8

9 Lenguaje Microensamblador. Hasta aquí escribimos el microprograma en lenguaje de máquina o microcódigo. Es posible definir un Micro-Assembler. Habría que definir el formato de la Microinstrucción. - Debe estar compuesto por campos. - Un microensamblador lo convierte a lenguaje de máquina. Nos quedaremos con el concepto solamente. 9

10 Microprogramación Microprogramación: Una de las estrategias para implementar la unidad de control de un procesador que consiste en programar al nivel de las operaciones de transferencia de registros (RTL). El control se µprograma, a esto se le llama firmware Una moneda con 2 caras: Hw y Sw. No son mundos distintos, son complementarios. Microarquitectura Estructura lógica y capacidades funcionales del hardware, tal como es visto por el microprogramador. Preguntas: Hay microprogramación estructurada similar a la progr. estructurada? Cuáles son los intereses del microprogramador? 10

11 El Microprograma como Intérprete de Macroinstrucciones. Main Memory CPU execution unit control memory ADD SUB AND... DATA Programa y Datos del Usuario Puede Cambiar! Ej. Cada MacroInstrucción Se mapea en una microsecuencia Microsecuencia Fija Fetch Calc Operand Addr Fetch Operand(s) Calculate Save 11

12 Implicancias Cambiando el ROM de Microprograma cambio el Set de Instrucciones. Puedo ampliar el set actual. Puedo hacer un set a medida para un procesador de propósito especial. Flexibilidad para corregir bugs. Puedo hacer que una máquina se comporte como otra. Emulación (sirve para migración). Familias de Computadoras (ej. IBM). Si se trata de microprogramar solamente: Puedo incorporar instrucciones poderosas. Cierro brecha semántica con lenguajes de alto nivel. Dio origen a CISC (Complex Instruction Set Computers). PARETTO! El 90% de las instrucciones son simples. Por agregar las complejas se complica el camino de datos y las simples se ejecutan más lentas. No se usa el contexto a nivel de microinstrucción. Difícil de implementar Pipelinine. 12

13 Microcódigo Vertical - Ejemplo Microcódigo Horizontal. Una salida de control para cada punto de control en la máquina. µseq µaddr A-mux B-mux bus enables register enables Microcódigo Vertical. Formato compacto y definido para cada clase de Microinstrucción. Se privilegia codificar para reducir tamaño de la µinst cond next address dst src alu Branch Jump Register Operation D E C D E C 13

14 Vertical Vs. Horizontal Ventajas y Desventajas de Cada Una Velocidad del CPU. Tamaño de la ROM de Microprograma. Aprovechamiento de lugar disponible en CPU - Otros elementos (ej. Caché más grande) Horizontal + Más posibilidades de emplear el paralelismo potencial de las actividades en el camino de datos. - Tamaño mayor de ROM Vertical + Fácil de programar, no muy diferente de programar en assembler para una máquina RISC. - Un nivel adicional de decodificación puede hacer más lenta la máquina. - Más lenta por no aprovechar - paralelismo. 14

15 Ventajas y Desventajas de la Microprogramación Facilidad de Diseño. Flexibilidad Se pueden hacer cambios más tarde. Se pueden implementar conjuntos poderosos de instrucciones. Generalidad. Se puede implementar distintos sets de Instrucciones en la misma máquina. Se pueden tener sets de instrucciones a medida. Compatibilidad. Distintas organizaciones de Hw, el mismo set de Instrucciones. Costoso para Implementar (ROM grande). Lento (CISC Vs. RISC) 15

16 Un camino de Datos Alternativo con Buses A-Bus next PC P C inst mem Reg A IR File S mem ZX SX B B Bus W-Bus En cada ciclo de reloj, cada uno de los buses puede realizar una única transferencia. 16

17 Qué tal con una arquitectura de 2 buses? Instruction Fetch next PC P C IR ZX SX Reg File A B S Mem M A-Bus B Bus Decode / Operand Fetch next PC P C IR ZX SX Reg File A B S Mem M 17

18 Load Execute next PC P C IR ZX SX Reg File A B S Mem M Mem next PC P C IR ZX SX Reg File A B S addr Mem M Write-back next PC P C IR ZX SX Reg File A B S Mem M Qué tal con 1 Bus? 18

19 Excepciones (Recapitulación) Programa Usuario Exception: System Exception Handler return from exception Excepción = transferencia de control no programada El S.O. Toma acción para manejar la excepción. Al terminar retorna el control al usuario. Debe guardar y restaurar el estado del Progr. Usuario. Permite la construcción de una máquina virtual del usuario. 19

20 Excepciones e Interrupciones (Recap) La parte más dura del diseño es el control. La parte más dura del control es para Excepciones. Eventos que cambian el flujo de las instrucciones y no son BRANCH ni JUMP. La excepción ocurre por un evento inesperado dentro del procesador (Ej. Overflow). Interrupción se debe a un evento inesperado externo al CPU, por ej. I/O. Convención MIPS: Excepción es un cambio inesperado en el flujo de control, independiente si su causa es externa o interna. Cuando es externo se le llama Interrupción. 20

21 Excepciones Interrupciones Traps Causada por eventos externos (ej. I/O) Asíncronas con la ejecución del programa. Se ejecutan entre instrucciones del programa. Simple: suspenda y continúe el programa del usuario. Causadas por eventos internos. - Condiciones excepcionales (overflow) - errores (parity) - Fallos (páginas de caché) Sincrónicas con la ejecución del programa. El problema debe ser remediado por el handler (rutina del SO). La instrucción se aborta y se reinicia una vez solucionado el problema, caso contrario se debe abortar el programa. 21

22 Cómo se manejan las Excepciones? El CPU debe guardar la dirección de la instrucción causante de la excepción en EPC (exception program counter) Transferir el control al Sistema Operativo en una dirección determinada. SO realiza alguna acción en respuesta a la excepción, luego reinicia la instrucción abortada mediante el EPC. 2 tipos de excepciones para nuestro ejemplo de implementación: instrucción indefinida y overflow aritmético. Cómo se sabe qué evento causa la interrupción? Opción 1 (MIPS): un Registro de Causa contiene el código de evento Opción 2 Interrupciones Vectoriales: Una dirección contiene la causa. 22

23 Adiciones al ISA del MIPS para soportar Excepciones EPC un registro de 32-bits que contiene la dirección de la instrucción afectada (registro 14 del coprocesador 0). CAUSE un registro que contiene el código de la causa de la interrupción. En la Arquitectura MIPS los registros son de 32 bits, por tanto muchos bits no se usan. Supongamos que el LSB de este registro codifica las dos fuentes de excepción mencionadas: Instrucción indefinida = 0 y overflow =1 2 Señales de control para escribir EPC y Cause Se requiere escribir la dirección del handler de la excepción en el PC, por tanto se incrementa un MUX para incorporar como entrada al PC: Es necesario deshacer PC = PC + 4, ya que queremos que EPC apunte a la instrucción afectada (no a su sucesora); PC = PC

24 Otros suplementos al ISA para tratar Excepciones BadVAddr registro que contiene la dirección de memoria en la cual ocurre una excepción por fallo de página Status mascara de interrupción y bits de habilitación 24

25 Cómo detecta las excepciones el control. Instrucción Indefinida: se detecta cuando no está definido un estado siguiente desde el estado 1, según el valor del op-code. Se define para esta excepción un nuevo estado siguiente al N 1, para todos los valores de op-code que no sean los definidos (lw, sw, (tipo-r), jmp, beq, ori), corresponderá al estado N 12. Simbólicamente lo señalamos mediante un op-code denomindado otro, indicando que el op-code no es ninguno de los que marcan las transiciones desde el estado 1. Overflow se agrega lógica al ALU para detectar esta condición y generar una señal de salida llamada Overflow. Esta señal se usa en la MEF modificada para señalar una transición a un nuevo estado a partir del estado 7. Sólo las operaciones tipo-r pueden dar Overflow. Cuando se diseña el control de una máquina real, el desafío consiste en diseñar el control para manejar diferentes interacciones entre instrucciones y otros eventos causantes de excepciones, manteniendo la lógica de control pequeña y rápida. Interacciones complejas hacen que el diseño del control sea todo un desafío. 25

26 Cambios al Diagrama de Estado para Excepciones IR ß MEM[PC] PC ß PC + 4 undefined instruction A ß R[rs] B ß R[rt] other EPC ß PC - 4 PC ß exp_addr cause ß 0 (UI) R-type S ß A fun B ORi S ß A op ZX LW S ß A + SX SW S ß A + SX BEQ S ß A - B 0010 overflow M ß MEM[S] MEM[S] ß B R[rd] ß S R[rt] ß S R[rt] ß M EPC ß PC - 4 PC ß exp_addr cause ß 1 (Ovf) 26

27 Volviendo al Diagrama de Estados Detallado 2 0 Ifetch ALUOp=Add 1: PCWr, IRWr x: PCWrCond RegDst, Mem2R Others: 0s 1 Rfetch/Decode 8 ALUOp=Add AdrCal 1: BrWr, ExtOp beq 1: ExtOp ALUSelB=10 ALUSelA x: RegDst, PCSrc ALUSelB=11 IorD, MemtoReg ALUOp=Add Others: 0s lw or sw Other x: MemtoReg PCSrc Ori lw sw 12 Rtype 3 RExec 1: RegDst SWMem ALUSelA 1: ExtOp LWmem 5 6 ALUSelA, IorD 1: ExtOp ALUSelB=01 ALUOp=Rtype ALUSelB=11 MemWr ALUSelA x: PCSrc, IorD ALUOp=Add ALUSelB=11 MemtoReg x: MemtoReg ALUOp=Add ExtOp PCSrc x: PCSrc,RegDst MemtoReg Rfinish 1: ALUSelA 7 ALUOp=Rtype 4 LWwr RegWr, ExtOp MemtoReg 1: RegDst, RegWr ALUselA ALUSelB=11 Overflow ALUOp=Add ALUSelB=01 x: PCSrc x: IorD, PCSrc IorD 13 ExtOp BrComplete ALUOp=Sub ALUSelB=01 x: IorD, Mem2Reg RegDst, ExtOp 1: PCWrCond ALUSelA PCSrc 10 OriExec ALUOp=Or 1: ALUSelA ALUSelB=11 x: MemtoReg IorD, PCSrc 11 ALUOp=Or x: IorD, PCSrc ALUSelB=11 1: ALUSelA RegWr OriFinish 27

28 Camino de Datos y Señales para Excepciones. 1 0 Cuál es el camino para RFE? (Return From Exception) 0 Cause IntCause CauseWr EPCWr=1 EPC PCWr=1 PC IorD=0 0 Mux PCWrCond=x Zero MemWr=0 32 RAdr Ideal Memory WrAdr Din Dout 32 IRWr=0 Instruction Reg A PC busa busb ALUSelA= PCSrc=11 0 Mux Mux BrWr=x EAddr 32 ALU ALU Control Target Zero 32 ALUSelB=00 ALUOp=Sub 28

29 Estados adicionales para manejar Excepciones 12 Instr Ilegal 15 Se puede mejorar? Ifetch 0: IntCause 1: CauseWrite x: RegDst, PCSrc ALUOp, ALUSelB IorD, MemtoReg Others: 0s PCdec 1: EPCWrite 0: ALUSelA ALUSelB=00 ALUOp=Sub x: MemtoReg PCSrc, PCex : PCWr PCSrc=11 x: RegDst, ALUOp, ALUSelB IorD, MemtoReg Others: 0s Habrá algo a hacer en paralelo? ALUOp=Add 1: PCWr, IRWr x: PCWrCond RegDst, Mem2R Others: 0s 13 OVflw Other 1: IntCause 1: CauseWrite x: RegDst, PCSrc ALUOp, ALUSelB IorD, MemtoReg Others: 0s Rfetch/Decode ALUOp=Add 1: BrWr, ExtOp ALUSelB=10 x: RegDst, PCSrc IorD, MemtoReg Others: 0s Rtype RExec 1: RegDst ALUSelA ALUSelB=01 ALUOp=Rtype x: PCSrc, IorD MemtoReg ExtOp Rfinish ALUOp=Rtype 1: RegDst, RegWr ALUselA ALUSelB=01 x: IorD, PCSrc ExtOp lw or sw Overflow beq ori

30 Qué pasa con la Instrucción con excepción? Pueden aparecer algunos problemas, según la forma en que se maneje la excepción. Por ejemplo, para el caso de overflow, la instrucción que la causa escribe su resultado, debido a que se pasa al estado de overflow después que se completa el estado de escribir el resultado. Propuesta de Solución? La arquitectura debe definir que las instrucciones no alteren el estado cuando hay excepciones; el MIPS especifica esto. Cuando veamos memoria virtual, veremos que aparecen ciertas clases de excepciones que deben evitar que la instrucción cambie el estado del CPU. Este aspecto del manejo de excepciones es complejo y limita potencialmente la performance. 30

31 Resumen El Control es la parte más difícil del diseño de un CPU. La Microprogramación especifica al control como un programa en micro-ensamblador en vez de un diagrama de MEF. La Microprogramación es un método de especificación del control, útil cuando el control es complejo. El microprograma se ensambla y se obtiene la tabla de verdad, la que puede realizarse con ROM o PLA empleando CAD. Las excepciones son la parte difícil del control. Es necesario encontrar un lugar conveniente para detectar excepciones y saltar al estado que guarde el PC, cargue el registro CAUSE e invoque al Sistema Operativo. Para el caso de CPU con pipeline, y fallos de memoria virtual: la instrucción no se puede completar y debe ser posible resumir el programa en exactamente la misma instrucción que tuvo el fallo, se pone todavía más difícil. 31

32 Microprogramación: una inspiración para RISC Si una instrucción simple pudiera ejecutarse en un ciclo de reloj (al igual que una µinst). Si uno pudiera escribir programas que produzcan microinstrucciones (compilar más abajo). Si la mayoría de los programas usaran instrucciones y modos de direccionamientos simples (como µprog. Vertical) Si el microcódigo se guardara en RAM y no en ROM para solucionar errores Si en lugar de la ROM pusiéramos un cache para macroinstrucciones Entonces, por qué no saltear el microprograma y compilar directamente en al nivel más bajo de código en la máquina? Objetivo: 1 macroinstrucción en 1 T. 32