L’automate doit maintenant pour chaque instruction
- aller chercher l’instruction (la stocker dans le registre d’instruction)
- aller chercher l’adresse de l’opérande (le stocker, dans un registre dit "d’adresse")
- aller chercher l’opérande proprement dit, en lisant la RAM à l’adresse stockée au cycle précédent.
On a donc une machine qui possède un état de plus (celui où on va lire en RAM l’opérande proprement dit).
1 Les adresses
Maintenant, on n’accède plus à la RAM de façon linéaire. Dans l’exemple de programme donné, les adresses présentées à la RAM seront celles-ci :
- 0
- 1
- 100
- 2
- 3
- 101
- 4
- 5
- 102
- …
Les adresses de code sont globalement linéaires (0, 1, 2, 3, …), celles des données ne le sont pas (elles sont arbitraires). Il faut donc présenter sur le bus d’adresse RAM
- soit le compteur d’adresse pendant les deux premiers cycles (et on l’incrémente à chaque fois)
- soit le contenu du registre d’adresse (adresse de l’opérande à aller chercher) pendant le troisième cycle (et ici le compteur d’adresse ne doit pas être incrémenté)
donc : multiplexeur…
De plus, le compteur d’adresse doit être piloté par un signal INCR_PC : il n’est incrémenté que si INCR_PC est à l’état haut.
Le registre d’adresse est chargé au cycle numéro 2. Son contenu n’est utile qu’au cycle numéro 3. Il n’est donc pas nécessaire de le piloter avec un enable…Il peut rester tout le temps actif : son contenu sera indéterminé pendant les cycles 1 et 2, mais ce n’est pas grave, il n’est pas utilisé pendant ces cycles là…
L’architecture globale est donc celle représentée sur la figure 1.8, et son graphe d’états en figure 1.9.


C’est, ici encore, une machine de Mealy, et ses équations sont :
LOAD_ACC = (I[7:0] <> STORE) ET (Etat = Ex)
WRITE = (I[7:0] == STORE) ET (Etat = Ex)