A menos que proporcione el enlace quién lo ha sugerido y por qué, hay un campo enorme para adivinar y especular. No conozco la respuesta correcta a su pregunta y creo que puede ser simplemente histórica.
Considera lo siguiente:
- La afirmación que citó es en realidad cierta; el conjunto de RAM más grande (y los registros están organizados como SRAM) requirió circuitos de decodificación más grandes, por lo que más registros llevan a más retrasos y, por lo tanto, los diseñadores de la CPU RISC deberían reducir la velocidad del reloj para un funcionamiento confiable de la CPU;
- Mire este artículo , página 8. RISC con 32 registros Contra los 16 registros de CISC fue de todos modos el gran avance en la computación. Puede ser que la cantidad de registros haya sufrido el mismo mito de la declaración de RAM de 640 KB de Bill Gates, y que se haya considerado (y tal vez aún) que 32 registros son suficientes;
- La discusión sobre tener muchos registros en el núcleo es similar al tener una gran cantidad de caché. Se realizó una importante investigación sobre el tamaño de la memoria caché, y (que yo sepa) se demostró que los tamaños de memoria caché más grandes pueden afectar negativamente al rendimiento. Así lo mismo con los registros; para la aplicación de software de administración de datos y matemática de propósito general, 32 registros (32 enteros más 32 puntos flotantes) pueden ser suficientes (mi opinión personal);
- Sería lógico concentrarse en aumentar la velocidad de acceso a la RAM principal en lugar de aumentar el conjunto de registros. Puede aumentar el número de registros a 1024, con un aumento significativo en el costo de silicio, pero puede aumentar fácilmente la RAM externa de 256 MB a 16 GB con una fracción de ese costo.
Como conclusión, la arquitectura de la CPU depende del propósito para el que está diseñada, las tareas que realizará y el tipo de operaciones que realizará; tamaño de la RAM inmediata requerida (registros), tamaño de toda la RAM requerida, etc. Y, por supuesto, el costo de la CPU y su lógica de soporte.
Actualizar:
pero nunca menciona el hecho de que 32 registros no es suficiente
Suficiente o insuficiente espacio de registro es una cuestión subjetiva; algunas personas consideran que los registros de 12 * 16 bits son suficientes cuando la aplicación puede acceder a 64 KB de RAM. Mucha gente codifica en lenguaje de alto nivel en estos días, por lo tanto, no se preocupa por el conjunto de registros, el compilador se encarga de la conversión en ejecutable.
Las CPU tienen en realidad al menos 80 y, a veces, más de 100 registros físicos
Nombrar nuevos registros dentro del lenguaje ensamblador (en otras palabras, dar un código que ejecute el acceso directo a esos registros) requiere una estandarización. Puede ser que alguien se atreva a actualizar 32 registros accesibles directamente en 64, 128 o 256 registros, y luego tratar de promover nuevos estándares en las masas. Probablemente no sea económicamente viable en este momento.
Entonces, ¿por qué el motivo por el que se adhiere a 32 registros de arquitectura?
¿Quizás por razones de compatibilidad? Imagine que libera una CPU que admite 512 registros direccionables directamente, y los desarrolladores comenzarán a programarlo (utilizando ensamblador o mediante compilador). El código de bajo nivel resultante no será fácilmente transportable a sistemas con un conjunto de 32 registros.
implica gastar muchos recursos en el cambio de nombre de registro
Renombrar no se trata solo de usar registros adicionales disponibles; esta técnica tiene más que ver con el paralelismo y el rendimiento obtenido con ella, incluido el código disponible actualmente (y ya ensamblado) para el conjunto de 32 registros .