Sur les architectures actionnées par déplacement (transport triggered architectures), les instructions machine correspondent directement à des micro-instructions. La raison d'exister de ces architectures est tout autant la simplicité du processeur que la performance. Le séquencement des micro-instructions n'est pas réalisé par le processeur, mais par le compilateur. De fait, le séquenceur devient extrêmement simple et utilise peu de portes logiques. De plus, le fait que le compilateur ait la main sur les micro-instructions peut permettre des simplifications assez fines, qui ne seraient pas possibles avec des instructions machines normales. Par exemple, on peut envoyer le résultat fourni par une unité de calcul directement en entrée d'une autre, sans avoir à écrire ce résultat dans un registre intermédiaire du banc de registres. Par contre, la portabilité des programmes compilés pour de telles architecture est faible. La raison est que les micro-instructions ont un temps de latence à prendre en compte. Sans cela, on pourrait par exemple lire une donnée avant que celle-ci ne soit disponible. Si les temps de latence changent, les programmes peuvent se mettre à dysfonctionner.

Architecture déclenchée par déplacement (Transport Triggered Architecture).

Le jeu d'instruction d'un processeur actionné par déplacement

Comme dit plus haut, les instructions machines de ces processeurs sont identiques aux micro-instructions. Chaque instruction du langage machine configure directement le bus interne au processeur. Elles peuvent relier les ALU aux registres, relier les registres entre eux, effectuer un branchement, etc.

Les instructions sont plus longues que pour les autres processeurs. La raison est que les micro-instructions d'un processeur normal sont plus longues que les instructions machines. Les micro-instructions ont en effet besoin de préciser beaucoup de choses que les instructions machines normales peuvent passer sous silence. Une micro-instructions a par exemple besoin de préciser comment configurer le bus interne, le banc de registres, l'unité de calcul, l'unité de gestion mémoire, etc. A l'inverse, une instruction normale a juste besoin de préciser l'opération à faire, la localisation des opérandes/résultats, éventuellement le mode d'adressage, et quelques autres détails. Le second ensemble d'information est généralement codé efficacement, de manière à utiliser peu de bits. Par contre, les bits de configuration du bus interne sont ce qu'ils sont et on peut rarement en limiter le nombre pour compresser la micro-instruction.

En conséquence, la code size est généralement mauvaise sur ces processeurs. Mais ce n'est pas lié qu'à la taille des instructions : le nombre d'instructions par programme augmente lui aussi. N'oublions pas qu'une instruction machine correspond à une séquence de plusieurs micro-instructions. Le nombre d'instructions est donc multiplié en conséquence. Et les optimisations qui permettent d'économiser les micro-instructions n'y font pas grand chose. S'il est possible d'éliminer certaines micro-instructions redondantes, dans certaines circonstances, cela ne compense pas le fait que le nombre total d'instructions machines est multiplié par 3 ou 4.

Sur certains de ces processeurs, on n’a besoin que d'une seule instruction qui permet de copier une donnée d'un emplacement (registre ou adresse mémoire) à un autre. Pas d'instructions LOAD, STORE, etc. : on fusionne tout en une seule instruction supportant un grand nombre de modes d'adressages.

L'implémentation des processeurs actionnés par déplacement

On peut implémenter ces architectures de deux manières : soit en nommant les ports des unités de calcul, soit en intercalant des registres en entrée et sortie des unités de calcul.

L'implémentation avec des ports

Dans le premier cas, l'instruction machine connecte directement l'ALU sur le bus interne. Mais avec cette organisation, les ports de l'ALU (les entrées et sorties de l'ALU) doivent être sélectionnables. On doit pouvoir dire au processeur que l'on veut connecter tel registre à tel port, tel autre registre à un tel autre port, etc. Pour ce faire, les ports sont identifiés par une suite de bits, de la même manière que les registres sont nommés avec un nom de registre : chaque port reçoit un nom de port. Il existe un port qui permet de déclencher le calcul d'une opération. Quand on connecte celui-ci sur un des bus internes, l'opération démarre. Toute connexion des autre ports d'entrée ou de sortie de l'ALU sur le banc de registres ne déclenche pas l'opération : l'ALU se comporte comme si elle devait faire un NOP et n'en tient pas compte.

Architecture déclenchée par déplacement - microarchitecture avec des ports.

L'implémentation avec des registres

Dans le second cas, on intercale des registres intermédiaires spécialisés en entrée et sortie de l'ALU. Le but de ces registres est de stocker les opérandes et le résultat d'une instruction. Certains de ces registres servent à déclencher des instructions : lorsqu'on écrit une donnée dans ceux-ci, cela va automatiquement déclencher l’exécution d'une instruction bien précise par l'unité de calcul. Les autres registres ne permettent pas de déclencher des opérations : on peut écrire dedans sans que l'ALU ne fasse rien. Par exemple, un processeur de ce type peut contenir trois registres « ajout.opérande.1 », « ajout.déclenchement » et « ajout.résultat ». Le premier registre servira à stocker le premier opérande de l'addition. Pour déclencher l'opération d'addition, il suffira d'écrire le second opérande dans le registre « ajout.déclenchement », et l'instruction s’exécutera automatiquement. Une fois l'instruction terminée, le résultat de l'addition sera automatiquement écrit dans le registre « ajout.résultat ». Il existera des registres similaires pour la multiplication, la soustraction, les comparaisons, etc.

Architecture déclenchée par déplacement - microarchitecture avec des registres pour l'ALU.