¿Cómo diseñar eficientemente el código de operación para una CPU?

11

Estoy creando una CPU simple de 16 bits en Logisim y tengo preparada la ALU y los códigos de operación que quiero tener. Ahora me resulta realmente difícil encontrar la codificación correcta para los comandos, de modo que los diferentes subcircuitos (por ejemplo, lógica, aritmética) no necesitan todos los cables de control (que forman la codificación) como entrada, sino tan pocos como sea posible. ¿Existen estrategias o métodos que ayuden con un diseño de código de operación eficiente?

gracias por adelantado

    
pregunta Benjoyo

6 respuestas

9

Creo que es un buen enfoque para estudiar otros conjuntos de instrucciones.

Una pequeña sería la MSP430 de TI, es un procesador de 16 bits con aproximadamente 22 instrucciones.

enlace

También puedes mirar en los AVR de Atmel que también tienen un conjunto de instrucciones bastante pequeño.

En un pequeño proyecto mío, intenté desarrollar un procesador simple de 32 bits en VHDL con un pequeño conjunto de instrucciones (14 instrucciones):

enlace

Debido a mi tiempo libre actual, no está completamente terminado. Las instrucciones están implementadas, pero dos no están probadas y quizás falten algunos indicadores de estado.

    
respondido por el TM90
7

Estudie (pero no replique) el enfoque ARM para la codificación de instrucciones. Es muy orientado a los prefijos (como el enfoque de árbol de Huffman recomendado por Dzarda) y altamente uniforme en cuanto a dónde se encuentra el registro que selecciona parte de la instrucción.

El enfoque poco imaginativo pero confiable es enumerar todas las señales de control que tiene, que probablemente tengan más de 16 bits, y luego intentar minimizarlas en la lógica del estilo del mapa de Karnaugh.

    
respondido por el pjc50
4

Una vez intenté hacer una CPU de 4 bits con un núcleo de longitud de instrucción de 8 bits en Logisim. Terminé con una máquina de estado simple, más que una CPU, en realidad.

Cosas aleatorias para buscar

  • Huffman trees
  • ¿Codificación de longitud fija o variable?
  • ¿Es un diseño de von Neumann con un espacio de direcciones único o el estilo de Harvard con datos / programa separados?

Excelente video en Computerphile sobre árboles de Huffman:

  

enlace

    
respondido por el Dzarda
4

La ISA que escribí para la clase una vez tenía un código de operación de 4 bits así: 1XXX ALU instructions 01XX jump, jump register, call etc 001X branch not equal, branch equal zero 000X 0 - load, 1 - store

En lugar de ser el más óptimo, este es uno de los estilos más fáciles para construir / diseñar puertas porque la señal de entrada de un solo bit puede controlar completamente la ruta lógica que se toma. Alternativamente, puede Huffman Code sus símbolos más usados y ponerlos a cero para obtener un código operativo de longitud fija.

    
respondido por el user65335
3

Una cosa que deberá considerar es si debe permitir cualquier forma de instrucción de palabras múltiples, o cualquier cosa que pueda "actuar" como una instrucción de palabras múltiples; si lo hace, entonces puede querer considerar si usar palabras de instrucción adicionales después de la instrucción principal, o prefijo las palabras anteriores. Permitir que los prefijos y las palabras de seguimiento puedan aumentar la complejidad del manejo de interrupciones, pero puede evitar la necesidad de encajar instrucciones poco utilizadas en el mismo espacio de código de operación que las que se usan comúnmente.

Si se obtienen instrucciones en el ciclo antes de ejecutarse, se podría tener una instrucción de "rama condicional" que provoca que la siguiente palabra de instrucción se salte o que su contenido se transfiera directamente al contador del programa; Un diseño de este tipo podría agregar cierta complejidad adicional para interrumpir la secuenciación, pero podría aliviar la necesidad de utilizar una gran parte del espacio del código de operación para las instrucciones de "ramificación", "salto" y "llamada", al tiempo que permite un rango mucho más amplio de condiciones de ramificación. de lo contrario sería posible. Dado que una rama que se toma generalmente requerirá un ciclo muerto después de la ejecución de la instrucción en sí, independientemente de de dónde provenga la dirección, tener la dirección proviene de la siguiente palabra que se recuperó pero no se ejecutará, no cuesta nada más. tiempo.

A pesar de que mover la dirección de destino fuera de las instrucciones de bifurcación reducirá la cantidad de espacio de código de operación que se engulen, un formato de código de operación de 16 bits todavía es bastante ajustado. Usar instrucciones de prefijo puede ayudar con eso. Si, por ejemplo, uno quiere tener 32 registros, permitir que cualquier registro se especifique de forma independiente como source1, source2 y destination requeriría 15 bits en el código de operación, lo que permite un total de dos instrucciones. No es muy útil. Por otro lado, sería bueno poder utilizar cualquiera de los 32 registros para cada uno de los tres operandos. Uno podría equilibrar los dos objetivos teniendo una operación de ALU que no esté precedida por un prefijo. Use ocho bits para hacer dos selecciones de registro uno de dieciséis, pero tiene una operación de ALU que sigue inmediatamente a un prefijo. Use algunos bits en el prefijo. con ocho de la siguiente instrucción, a fin de permitir la selección independiente de ambas fuentes y el destino del conjunto completo de 32. Las instrucciones que utilizan los registros superiores tomarían dos palabras / ciclos en lugar de uno, pero en algunos casos tal compensación podría bien vale la pena La mayor dificultad con el uso de prefijos es que uno debe evitar que ocurra una interrupción entre un prefijo y la siguiente instrucción o, de lo contrario, asegurarse de que si ocurre una interrupción allí, la instrucción después del prefijo seguirá usando los registros correctos [por ejemplo. al hacer que la lógica de guardado del contador de programa almacene la dirección de la última instrucción no prefijada ejecutada].

El uso de instrucciones de varias palabras hará que algunos aspectos del diseño sean más difíciles, pero puede reducir la necesidad de tomar otras decisiones difíciles.

    
respondido por el supercat
0

Este tipo tiene los mejores detalles para entender el cableado duro de la parte codificada de un decodificador, que explica las líneas de control para una CPU codificada: enlace Como puede ver, su elección en Opcodes realmente afecta la complejidad de la lógica de Decode.

    
respondido por el cmacdona101

Lea otras preguntas en las etiquetas