Los registros son los recuerdos más rápidos en una computadora. Entonces, si queremos construir una computadora con solo registros y ni siquiera cachés, ¿es posible? Pienso incluso en reemplazar los discos magnéticos con registros, aunque son recuerdos naturalmente volátiles. ¿Tenemos algunos registros no volátiles para ese uso? ¡Sería tan rápido! Me pregunto si eso podría suceder o no.¿Podemos tener una computadora con solo registros como memoria?
La razón por la que obtienes tan poca memoria de registro es porque es increíblemente costosa. Es por eso que tenemos la jerarquía de memoria.
No necesita ni siquiera registros: es posible crear algo así como una máquina de Turing que transmita el código y los datos de entrada y produzca un flujo de salida. Esto es algo con lo que comenzaron las computadoras.
Creo que necesitamos recuerdos, la máquina Turing incluso necesita memoria para mantener el estado de la máquina aunque no sé cómo podría implementarse esa máquina en la vida real. – Kamran
Es posible, pero absolutamente poco práctico - incluso las computadoras de gama baja tienen 2 gigabytes de RAM. ¿Cómo manejaría dos mil millones de registros en código (y dónde los rellenaría físicamente)?
Además, ¿qué harías con eso, que la velocidad de la RAM (e incluso las cachés del procesador) es una preocupación? Ejecute el sistema fuera de la RAM (lo suficientemente rápido) o cree un procesador de propósito especial.
2 mil millones de registros requieren uno o más campos de registro de 31 bits en cada instrucción. Propongo que el campo de registro sea una palabra separada de 32 bits fuera del código de operación básico. Yo físicamente ponía los registros en un chip o fichas separadas.Obviamente, eso dará lugar a una penalización de rendimiento, por lo que tendría un pequeño conjunto de "ultraregistros" en el chip de la CPU. – JeremyP
Los registros son rápidos porque la mayoría de los registros están conectados directamente a la mayoría de las unidades funcionales. Mientras un programa está cargando un registro, otro registro está alimentando a la ALU y otro registro está escribiendo un resultado de alguna otra unidad funcional.
Los registros se realizan con elementos lógicos como flip-flops, de modo que la mayoría de los valores de la mayoría de los registros están todos disponibles al mismo tiempo, todo el tiempo. Esto es diferente de una memoria en la que solo está disponible una dirección seleccionada en cualquier momento y solo hay disponible un número muy limitado de puertos de lectura. Típicamente, es solo un circuito de lectura.
Sin embargo, este tipo de implementación e interconexión es lo que usa el espacio del dado en el microprocesador. Cuando se agota, comienza a agregar memoria para almacenamiento adicional.
Ha habido arquitecturas con bancos adicionales de registros. (SPARC!)
El problema con eso es que los registros están presentes dentro de la CPU. Desde su presencia en la CPU, tiene una latencia mínima. También porque es de menor tamaño. Cuando aumentas el tamaño, digamos que consideras que construyes un gran procesador con muchos transistores (flip-flops) que contienen los registros, entonces la disipación de calor, el consumo de energía, el costo, etc. serán enormes. También cuando el espacio aumenta, la latencia también aumenta. Entonces, básicamente, no hay mucha diferencia al hacerlo. Es peor en realidad.
para cada registro de 32 bits necesita al menos 9x32 puertas de xor. eso es muchas puertas.
el problema mayor viene cuando desea que los datos de registro pasen por el bus. ¿cuál tendrá el bajo? ¿Quieres agregar más bajo?
digamos que tenemos 10 registros, ¿hacemos un bus de 10 líneas? lo que significa que tenemos 10 conectores de bus que se conectan a la mayoría del sistema? eso es un montón de cableado, ahora quieres que el registro signifique algo ¿no?
permite saber cuantos bajos necesitamos para 1kb de datos?
1024 bit = 1024 * 9 * 32 compuertas y 1024 líneas de bajo en la CPU.
sabemos que intel está trabajando con 30 nm para una puerta. eso es 30 millones de puertas, que el problema de la puerta más en peligro, pero ¿cómo va a resolver el problema de los graves?
La respuesta muy corta es sí, podría en teoría, pero realmente no funciona en la vida real. Me explico ...
La razón de ser de la jerarquía de memoria se debe a que esos pequeñas y rápidas almacenes de memoria son muy caros por un poco (registros), mientras que los grandes y lentos almacenes de memoria son muy baratas por un poco (discos duros).
Otra razón por la que un gran número de registros son muy poco prácticos es porque las instrucciones deben hacer referencia a la ubicación de la memoria. Cuando solo tiene un puñado de registros, puede almacenar el número de registro (o registros) y un código de operación en un puñado de bits, lo que significa que números bajos de registros hacen que las instrucciones rápidas y rápidas. Si va a tener una colección de registros de varios gigabytes, necesitará poder hacer referencia a ellos en las instrucciones, y estas serán instrucciones mucho más largas (y, por lo tanto, más lentas). Tenga en cuenta que si todo fuera un registro, algunas cosas serían mucho más rápidas, pero al tener un número menor de registros, ciertas cosas (es decir, la mayoría de lo que hace con una computadora) son mucho más rápidas.
Tener un gran número de registros que también añaden una gran cantidad de complejidad al hardware que procesa la lectura y la escritura a los registros, lo que haría todo más lento.
Por supuesto, aunque la mayoría de nosotros pensamos en términos de computadoras, seguramente existen dispositivos simples que solo tienen registros, pero también solo tienen una cantidad muy limitada de memoria y no están hechos para computación de propósito general .
Puede que le interesen también a my answer to Assembly: Why are we bothering with registers?
¡Gran respuesta, muy bien explicada! –
La mayoría de estas respuestas se ocupa de si sería práctico. David Johnstone también menciona el hecho de que un nombre de registro debe mencionarse en cada instrucción que lo toca. Además de esto, en la mayoría de los conjuntos de instrucciones modernas una instrucción siempre tiene sus registros de operandos codificados en ella. P.ej. está la instrucción mov %eax, %ebx, y está la instrucción mov %eax, %ecx. También puede ocurrir que su representación binaria aparece parecer:
| mov | source reg | dest reg |
| 2 | 3 | 3 |
y sólo difiere en que dest reg es igual a 3 en lugar de 2 - pero también puede no serlo! (No he comprobado cómo se representan estas instrucciones particulares en 386, pero recuerdo que hay ejemplos en ese conjunto de instrucciones de instrucciones que se pueden desglosar fácilmente en campos como este y ejemplos en los que no lo están).
El problema es que los programas más interesantes van a querer operar en ubicaciones de información, determinadas en tiempo de ejecución. P.ej. en esta iteración del ciclo, queremos ver el byte 37; la próxima iteración nos interesará el byte 38, etc.
no voy a demostrarlo, pero sospecho que con el fin de conseguir algo parecido a Turing completo, sus programas necesitarían ya sea:
En la escuela teníamos una computadora teórica con 100 registros (más el acumulador), y 10 instrucciones, cada uno de los cuales era un número decimal de tres dígitos. El primer dígito indicó la operación (cargar, guardar, aritmético, saltar, salto condicional, detener), y los dos últimos el registro para operar. Se podrían escribir muchos programas de ejemplo para esto, como la función factorial. Pero pronto se hizo evidente que un programa estático solo podía operar con un conjunto fijo de datos. Si quisiera escribir un ciclo para sumar los valores en una lista, necesitaría una instrucción LOAD que apuntara a un registro de entrada diferente en cada iteración. Esto significaba que calcularía aritméticamente el nuevo código para la instrucción de carga cada vez, y parchearía el código justo antes de ejecutar esa instrucción.
Las GPU modernas tienen aproximadamente 5 MB de registros y muy pocos cachés (en comparación con las CPU). Entonces sí, es posible tener un procesador con muchos registros.
Pero aún necesita una jerarquía de memoria (registros -> scratchpad/caches -> memoria del dispositivo -> memoria de la CPU). Tenga en cuenta también que las GPU son bestias completamente diferentes en el sentido de que están construidas con objetivos de paralelismo masivo desde el primer día y que las GPU no son de propósito general, sino coprocesadores.
Cada subproceso de la GPU consume algunos registros: todo el programa de la GPU está asignado al registro, lo que da como resultado miles de subprocesos que pueden ejecutarse/pausar/reanudar en paralelo. Los subprocesos se utilizan para ocultar la latencia de la memoria en las GPU, mientras que en las CPU se usan grandes cachés para ese fin. Piénsalo como Hyper-Threading llevado al extremo.
Caliente de la teoría de hardware de placa rouncer>
Si logra vincular cada permutación de los bits de dirección, a las palabras individuales - entonces usted podría tener un sistema de registro de carnero. imagina si usas nand para hacer los grupos de direcciones. (en otras palabras, enlace el opuesto de la dirección al flop) Uno no, y usted ha hecho el direccionamiento solo con cables + el pequeño no cambia, que podría ser una bobina de tipo solenoide que no tendrá el valor. luego, cada registro se envía a la misma salida: los pines de contenido. Y solo la dirección anterior, recibirá energía para los pines de contenido de salida.
simples.
Muchos uC son así, sin RAM, simplemente se registra. – leppie
¿Puedes dar un ejemplo? – Kamran
Dentro de ciertos límites, sí, pero no espere una memoria de registro de gigabytes. Además, el estado de la matriz es muy costoso y una limitación importante, además, el calor generado por el procesador se volvería inmanejable. Entonces, en general, la idea es inviable. –