« Fonctionnement d'un ordinateur/Les architectures dataflow » : différence entre les versions

La détection de la disponibilité des opérandes est primordiale sur les architectures dataflow. Suivant l'ordinateur utilisé, cette gestion du jeton peut être plus ou moins évoluée et peut permettre ou interdire certaines manipulations potentiellement intéressantes. Dans ce qui va suivre, on va voir qu'il existe différentes façons de gérer ce jeton. Le principal problème avec les jetons, c'est que ceux-ci doivent parfois attendre que leur instruction aieait réunie toutes ses opérandes pour être utilisés. Dans pas mal de cas, cela ne pose pas de problèmes : les jetons n'ont pas trop de temps à attendre et un nouveau jeton n'a pas le temps d'arriver entre temps. Mais ce n'est pas toujours le cas, et parfois, on peut se retrouver avec un nouveau jeton qui arrive avant que le précédent soit consommé. Dans ce cas, on est face à un problème : comment faire pour différencier l'ancienne donnée, qui doit être utilisée dans le calcul à faire, de la donnée du jeton nouveau venu ? La première solution est celle utilisée sur les '''architectures dataflow statiques'''. Sur ces architectures, on doit se débrouiller pour n'avoir qu'un seul jeton de disponible pour chaque opérande. Dit autrement, chaque flèche du graphe ne doit contenir qu'un seul jeton à la fois lors de l’exécution du programme. En clair, une instruction ne peut pas avoir plusieurs valeurs différentes d'une même opérande en attente, chose qui serait possible avec l'usage de boucles, par exemple.

Une instruction contient alors, outre son opcode, un espace pour stocker les opérandes (les jetons) et quelques bits de présence qui indiquent si l'opérande associée est disponible. Les jetons sont donc stockés dans l'instruction, et sont mis à jour par réecritureréécriture directe de l'instruction en mémoire. De plus, il ne faut pas oublier de représenter la flèche, les dépendances de données qu'elle peut avoir. Pour cela, chaque instruction contient l'adresse de l'instruction suivante, celle à laquelle envoyer le résultat. Tout cela ressemble aux entrées des stations de réservation sur les processeurs à exécution dans le désordre, à un détail près : tout est stocké en mémoire, dans la suite de bits qui code l'instruction. Vu qu'une instruction contient ses propres opérandes, on préfère parfois utiliser un autre terme que celui d'instruction et on parle d''''activity template'''.

En effet, il faut trouver un moyen de toujours respecter cette contrainte. Il faut empêcher une instruction de s’exécuter et de fournir un résultat si une autre donnée est en train d'attendre sur la même flécheflèche. Pour empêcher cela, chaque instruction contient un bit, un jeton d'autorisation qui indique si elle peut calculer un nouveau résultat. Quand une instruction s’exécute, elle prévient l'instruction qui a calculé l'opérande qu'elle est prête à accepter un nouvel opérande : le jeton de celle-ci est mis à jour. Pur que cela fonctionne, chaque instruction doit savoir quelle est la ou les instructions qui la précédent dans l'ordre des dépendances. Pour cela, une seule solution : stocker toutes leurs adresses dans l'instruction.