¿Por qué no tenemos más registros en los microprocesadores?

Question

En teoría, los registros no son necesarios; todos los microprocesadores seguirían funcionando sin registros. Pero esta adición aparentemente trivial ha ayudado a hacer que los microprocesadores sean más eficientes.

¿Por qué no podemos tener más registros para aprovechar aún más de ellos? Simplemente son memoria en el chip y se puede imaginar que no es muy difícil de añadir, ¿verdad? ¿Qué factor influyó en que el número de registros sea el que es ahora y no, por ejemplo, 10 veces más?

Answer 1

Hay varios factores:

• Las microarquitecturas de alto rendimiento utilizan renombramiento de registros. Es decir, el número de registros físicos es mayor que el número de registros arquitectónicamente visibles y son capaces de rastrear usos independientes de los mismos.

• Duplicar el número de registros no duplica el rendimiento. Recuerdo (de Arquitectura de computadoras, un enfoque cuantitativo) que pasar de 16 a 32 registros trae algo así como una mejora del 10% asumiendo que el aumento no tenga efectos adversos (lo cual es una suposición muy optimista).

• Los registros arquitectónicamente visibles tienen costos. Por ejemplo:

  • Aumentar su número aumenta la cantidad de bits utilizados en el formato de instrucción para indicar en qué registro se está actuando (doblar el número de registros implica tener un bit más por registro en el formato, lo que impide utilizar esos bits para otros usos o forzar un tamaño de instrucción más largo).
  • Aumentar el número de registros arquitectónicos aumenta el costo de cambio de contexto (ya que deben ser guardados y restaurados en el cambio de contexto).

Answer 2

Mientras que los registros y la RAM son ambos tipos de memoria, se acceden de diferentes maneras, reflejando el costo (en área de chip o ciclos de reloj ocultos) de acceder a ellos.

Los registros están estrechamente vinculados a la ALU y pueden desempeñar muchos roles, como fuentes de datos, sumideros, modificadores, etc. Por lo tanto, necesitan una gran cantidad de conexiones multiplexadas. En algunas arquitecturas podemos escribir R1 <= R2 + R3, y eso es exactamente lo que sucede en un solo ciclo de reloj. Cada registro es direccionado directamente en el código de operación, y esta dirección es un recurso bastante limitado.

Dado que los registros son costosos de implementar, generalmente su número está limitado al orden de 10/20 en la mayoría de las arquitecturas.

La RAM está menos vinculada a la CPU, generalmente canalizándose a través de una única conexión compartida. Esto hace que sea mucho más económico implementar una gran cantidad de RAM. Las direcciones de RAM generalmente provienen de una dirección almacenada en un registro, por lo que no consumen un ancho de instrucción significativo.

SPARC es una arquitectura interesante, con entre 72 y 640 registros de 64 bits, con un contexto de 32 registros que se pueden desplazar con solapamientos para llamadas rápidas a subrutinas con paso de parámetros. No es común encontrarlos en PCs y servidores donde el costo es importante, como ocurre en el 99.999% de las aplicaciones.

Answer 3

Los registros deben ser abordados dentro de la instrucción. Si hay muchos registros, la instrucción es más larga. Guardar y restaurar el contenido del registro para un servicio de interrupción requiere más tiempo si hay muchos registros.

Answer 4

Como la mayoría de las cosas, la cantidad de registros es un compromiso entre costo, complejidad y utilidad.

Los registros se implementan como RAM estática multi-puerto, lo que los hace más costosos (área de chip) que otras opciones de almacenamiento.

Luego se acoplan con el conjunto de instrucciones del procesador, aumentar la cantidad de registros aumenta la complejidad del conjunto de instrucciones. Por lo tanto, si desea mantener la compatibilidad con el conjunto de instrucciones, no puede simplemente aumentar la cantidad de registros disponibles en la próxima generación de procesadores para aumentar la eficiencia, los programas no los usarían.

¿Cuántos registros realmente necesita? Existe un límite para su utilidad. Considere que escribe un algoritmo que realiza alguna operación matemática en 1024 bytes, digamos multiplicar por 5. Con los conteos de registros actuales, terminaría con algo como:

cargar operando1=5
cargar dirección
bucle: cargar operando2=byte1@dirección
multiplicar Registro1 con Registro2
almacenar resultado
incrementar dirección
si dirección = fin ir a finBucle
saltar bucle
endLoop:

Ahora, si tuviera 1024 registros y todos los datos almacenados allí, su programa se vería así:

multiplicar Registro1 con Registro2
multiplicar Registro1 con Registro3
multiplicar Registro1 con Registro4
multiplicar Registro1 con Registro5
multiplicar Registro1 con Registro6
...

Debido a que cada uno es una instrucción diferente, cada uno de ellos debe escribirse. Así que su memoria de programa necesaria está creciendo exponencialmente. Después de darse cuenta de esto, es posible que desee introducir algunas instrucciones como multiplicar registro1 con registro(2 a 256). Pero, ¿cuándo parar, proporciona una instrucción para todas las combinaciones?

Entonces, tal vez los números que tenemos disponibles actualmente son un buen equilibrio entre costo, complejidad y utilidad.

Answer 5

Si echas un vistazo al conjunto de instrucciones de un procesador, hay varias formas de agruparlas. Por ejemplo, todas las instrucciones ADD podrían estar agrupadas juntas, al igual que todas las instrucciones XOR.

Dentro de cada grupo de instrucciones iguales, puede haber versiones que operan en la memoria o en registros. Es esta sub-agrupación la que define efectivamente el número de registros que tiene el procesador.

Como ejemplo hipotético de 8 bits, digamos que las instrucciones $Ax podrían ser las instrucciones ADD, y $Cx podrían ser las instrucciones XOR. ¡Con este diseño, solo quedan cuatro bits para definir los operandos!

• Uno podría tener solo cuatro registros de propósito general, y usar dos bits para definir uno, y dos bits para definir el otro.
• O, uno podría usar el primer bit para distinguir variantes "especiales", y los otros 3 bits para definir con qué uno de los ocho registros operar con el acumulador ($x0 podría ser el acumulador en sí mismo).
• O, uno podría tener más registros que este número, pero luego limitar qué registros son accesibles para qué instrucciones.

Por supuesto, ya hemos pasado de los conjuntos de instrucciones de 8 bits. Pero aún así, esta lógica ayudó a definir los conjuntos de registros en el pasado, y seguirá haciéndolo en el futuro.

EDICIÓN (según solicitud)

Digamos que los cuatro bits superiores son para la instrucción: ADD, SUB, XOR, MOV, CMP etc. Hay 16 posibilidades aquí. Luego, para aquellas instrucciones donde tiene sentido de registro a registro (por ejemplo ADD Rx, Ry), necesitas especificar Rx y Ry. Digamos que los dos siguientes bits son para x, y los últimos dos son para y. Por lo tanto:

ADD R1, R2  => 'ADD' + 'R1' + 'R2' => $A0 + $04 + $02

Con solo dos bits para definir un registro de esta manera, ¡solo tienes espacio para un total de cuatro registros!

Como nota aparte, notarás que algunas combinaciones de registros no tienen sentido. Por ejemplo, MOV Rx, Rx (no hace nada) y SUB Rx, Rx (siempre produce 0). Estas podrían convertirse en instrucciones de casos especiales:

1. SUB Rx, Rx podría convertirse en NOT Rx - una instrucción de un solo operando.
2. MOV Rx, Rx podría convertirse en una instrucción MOV que tome un segundo byte como un valor inmediato, interpretado como MOV Rx, #$yy.

De esta manera, puedes "jugar" con el mapa de instrucciones, llenando los vacíos para instrucciones de lo contrario inútiles o sin sentido para proporcionar un conjunto de instrucciones más grande para el programador. Pero en última instancia, el conjunto de instrucciones define el conjunto de registros.