Estaba leyendo algo acerca de los procesadores de ciclo único y de ciclo múltiple y tengo (parece ser) una pregunta banal: ¿cómo guarda el procesador el ciclo múltiple (que no tiene una canalización parejo) su próximo estado? ¿No se ejecuta hasta que actualmente no se ejecuta uno? ¿Está bloqueando el inicio de la primera fase de alguna manera?
De hecho, el inicio de la siguiente instrucción está bloqueado.
La forma habitual de modelar sistemas de múltiples estados es mediante el uso de "máquinas de estados finitos": es una lógica HW que cambia entre numerosos estados según:
Las salidas de un módulo controlado por FSM también están definidas por el estado de FSM y las entradas.
¿Qué pasa en nuestro caso? La nueva instrucción solo se puede recuperar en el estado inicial: llamémosla IDLE. Una vez que se obtuvo la instrucción, el FSM comienza a cambiar entre los estados operativos (por ejemplo: IDLE- > DECODE- > EXECUTE- > WRITE-BACK- > IDLE). Cuando se encuentra en un estado que no es IDLE, se prohíbe que la lógica obtenga nuevas instrucciones. Por lo tanto, la nueva instrucción comenzará a ejecutarse solo después de que finalice la anterior.
Diferentes procesadores difieren en los diseños de sus máquinas de estado, pero en muchos casos cada instrucción comienza en algún estado cero (búsqueda de código de operación), y la progresión de estados se pone en movimiento por el código de operación que se busca y cualquier código de operación dado siempre realice la misma secuencia de operaciones excepto que puede haber disposiciones para las instrucciones de salida temprana en ciertos casos, como "rama no tomada".
En el 6502, el estado cero, además de obtener un código de operación, puede realizar los últimos pasos de la instrucción anterior si no implica nada más que calcular un resultado de ALU y almacenarlo en un registro. El 6502 no permite la desviación de la secuencia de pasos para ningún código de operación que no sea a través de la salida temprana, pero una instrucción como "ADC # $ 1234, X" se comporta de la siguiente manera:
0 -- Finish previous instruction and fetch opcode
1 -- Fetch first byte following opcode [done unconditionally]
2 -- Fetch second byte following opcode into upper-address register
while adding just-fetched byte to X
3 -- Concatenate upper-address register with ALU result and read mem into data register
while feeding upper-address register and 1 into ALU.
If step 2 didn't generate carry, exit.
4 -- Load ALU result into upper half of address register and read mem into data register.
(next cycle)
0 -- Feed newly-fetched value into ALU along with accumulator; store ALU into acc.
Es interesante observar que las instrucciones que leen un valor de una ubicación de memoria indexada, operan en él y ponen el resultado en un registro pueden salir temprano si no se transfieren los 8 bits más bajos de la dirección, pero Las instrucciones que necesitan hacer más con el resultado obtenido no pueden omitir ningún paso. Por INC $ 1234, X
0 -- Finish previous instruction and fetch opcode
1 -- Fetch first byte following opcode [done unconditionally]
2 -- Fetch second byte following opcode into upper-address register
while adding just-fetched byte to X
3 -- Concatenate upper-address register with ALU result and read mem into data register
while feeding upper-address register and 1 into ALU.
4 -- If carry, load ALU result into upper half of address register (otherwise leave alone)
...and read mem into data register.
5 -- Store data register to memory
While feeding data register and 1 into ALU; latch ALU to data register
6 -- Store data register to memory
Tenga en cuenta que si el cálculo de la dirección en el paso 2 no genera un acarreo, sería posible omitir el paso 4, pero la lógica de secuencia de instrucciones no tiene ningún concepto de cómo omitir parte de una instrucción que no sea la cola, y los pasos 5 y 6 siguen siendo necesarios.
Curiosamente, aunque el mayor número de ciclos requerido para cualquier código de operación 6502 documentado es siete (ilustrado arriba), un 6502 vintage que encuentra ciertos códigos de operación no documentados los ejecutará de manera lógica como códigos de operación de ocho ciclos. La instrucción CMP 110xxx01 puede aceptar cualquiera de los ocho modos de direccionamiento, dos de los cuales toman un ciclo más largo que el modo de direccionamiento absoluto indexado que se muestra arriba, pero la instrucción no hace nada después de calcular la dirección. El DEC documentado (110xxx10) solo acepta cinco modos de direccionamiento (no acepta los más complicados), pero un byte de opcode que "superpone" a esos (110xxx11) combinará los efectos de DEC y CMP, y admitirá todos los modos de direccionamiento que hace CMP, incluso aquellos que terminan tomando un total de ocho ciclos. Me pregunto por qué los códigos de operación "normales" de lectura-modificación-escritura no pueden usar esos modos de direccionamiento, ya que los circuitos obviamente existen para hacer que tales modos de direccionamiento funcionen correctamente con las instrucciones de lectura-modificación-escritura.
Lea otras preguntas en las etiquetas microprocessor clock processor