Discussion :

[mrjay42]

Bonjour à tous,

Je suis en train de reprendre mes études et j'ai attaqué un master en informatique embarquée...hélas, venant du coté obscur (a.k.a : le développement web) j'ai de grosses lacunes en architecture.

Or me voici donc face à un problème concernant des bouts de code d'assembleurs (très courts) et je dois dire comment se comporte le pipeline.

Voici le détail de l'exercice sur lequel je bloque (ensuite j'indique aussi mes idées de réponses...

On a donc un pipeline en 5 étapes.
IF : on fetch les instructions
ID : on décode l'instruction et on lit les registres
X : on exécute ce qu'il y a à faire
M : on accède à la mémoire si nécessaire (load ou store)
W : on écrit dans le registre ce qui a été calculé


Il faut donc que j'indique comment les instruction des différents morceaux de code d'assembleur ci-dessous sont exécutées dans le cadre de ce pipeline.

Voici les bouts de code

Code 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CMP R1, #0 ; compare R1 to zero
BEQ label1 ; branch to label1 if equal (assume R1 ≠ 0)
ADD R2, R1 ; add R1 to R2
SUB R3, R4  ; subtract R4 from R3

Code 2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ADD R0, R1 ; add R1 to R0
SUB R2, R0 ; subtract R0 from R2

Code 3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
LOAD R1, 20(R2) ; load the value at Mem(20+[R2]) into R1
SUB R0, R1 ; subtract R1 from R0
STORE R0, 20(R3) ; store R0 into Mem(20+[R3])

Il faut décrire l’exécution de ces bouts de code avec un pipeline SANS forwarding et avec un pipeline AVEC forwarding. (forwarding = on peut utiliser un résultat directement après son exécution)

A cette adresse vous trouverez les résultats de mon travail :
http://www.scribd.com/doc/66268398

C'est un fichier Excel...Nettement plus facile de présenter mon travail dans un fichier Excel quand dans un tableau sur le SDZ.
Si ça pose problème dites le moi et je mettrai tout ça dans le forum.

Je vous remercie par avance si vous pouvez m'aider

[edfed]

avec ou sans pipeline, l'execution d'une instruction reste une sequence de divers microcodes.

charger une valeur dans un registre de travail est une etape, additionner les valeurs de deux registres de travail en est un autre.

par exemple, l'instruction ADD se fait ainsi:

prefetch instruction, charger l'instruction depuis la mémoire RAM vers le decodeur d'instruction

decode instruction, permet de generer la microsequence suivante
load value1, load value 2, add value 2 to value 1, store result in value 1

suivit de l'execution de chaque etape precedement calculée par le decodeur.

si le forwarding est actif, il faut absoluement attendre que l'execution precedente soit terminée avant de lancer la suivante. ce qui est en fait de la serialisation.

avec ou sans forwarding, l'algo reste le meme, dans l'un, les microcodes de chaque instruction (load, add, store) sont entrelacés dans le pipeline selon le type.
sinon, ils sont mis en serie dans le pipeline, instruction après instruction, c'est à dire, suite de microcodes après suite de microcodes. et donc, aucun microcode d'une instruction ne pourrat etre après un microcode d'une instruction n+1.


par exemple, en ecrivant un code au hazard:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
mov eax,ebx
add eax,2000
mov ecx,eax

sans forwarding:

mov eax,ebx devient:
load ebx in W (W peut etre concideré comme le tampon interne de l'unité d'execution)
store W in eax

add eax,2000 devient:
load 2000 in W
load eax in X (X est interne, comme W)
add W to X
result in Y
store Y in eax

et mov ecx,eax devient:
load eax in W
store W in ecx

.

la suite est simple et ne fait intervenir que le bon sens et la logique.

le store W in ecx ne pourrat evidement pas avoir lieu avant le load 2000 in W, pour la simple raison que le nombre 2000 est utilisé dans l'addition juste avant.

la seiralisation des instrucitons est indispensable pour ne pas avoir d'erreurs.




et donc, pour ce qui est de ça:

On a donc un pipeline en 5 étapes.
IF : on fetch les instructions
ID : on décode l'instruction et on lit les registres
X : on exécute ce qu'il y a à faire
M : on accède à la mémoire si nécessaire (load ou store)
W : on écrit dans le registre ce qui a été calculé

peut importe les denominations, M, W, ID, ou autres, l'essentiel est de comprendre que rien n'est instantané. meme les micro-operateurs peuvent etre decomposés nanoops, et ainsi de suite.

le tout est de savoir, où some nous reelement?

les micro operateurs (ou micro-codes) sont l'affaire exclusive du fondeur, intel entre autres, qui lui à un avantage certain à se pencher dessus. mais pour ce qui est du programmeur, systeme ou non, ces notions n'ont aucun interet. tout ce qui compte est le resultat d'une instruction en langage machine, et non celui des microcodes.

mais c'est une notion interessante pour la culture generale du programmeur, ça permet de realiser à quel point certaines instructions sont bancales pour telle ou telle tache. ça permet aussi de pouvoir optimiser au maximum, car en decomposant en microcodes, certaines simplifications peuvent apparaitre, ce qui se traduit en la suppression d'une ou plusieurs instructions assembleur. ce qui n'est pas negligeable.

bonne chance pour la suite, et si tu n'as pas compris, c'est normal, car meme en comprenant, on s'y perd, entre les instructions, les microops, les pipelines, les unités d'execution paralelle, etc... bref, une chose après l'autre.

on pourrait ecrire une encyclopedie sur les micro ops, sans pour autant trouver les mots justes. il s'agit surtout d'un effort personnel pour comprendre, je le repete, decomposition en operations elementaires, et execution d'une chose après l'autre. imagine qu'un CPU est en fait un simple mecanisme tout bete à base d'engrenages, l'impulsion electrique fait tourner le rotor, le rotor entraine un pignon, qui a son tour en entraine un autre, et au final, l'aiguille indique la bonne heure.

[bifur]

je souhaiterait poser un petite question:
il me semble qu'il existe un procédé (dont je ne me souvien pas du nom) qui permet au processeur d'accélerer l'execution d'instruction, dans le détail je ne sait plus comment ça marche mais le principe est le suivant:
le chargement de l'instruction, son décodage, le chargement des variable, l'execution de l'instruction, la sauvegarde des variables sont executé par plusieurs circuit séparé, ce qui permet de faire plusieurs chose en même temps, par exemple:

on charge l'instruction N°1
pandant que l'instruction N°2 est chargé, l'instruction N°1 est décodé
pandant que l'instruction N°2 est décode, on charge les variables nécessaire a l'instruction N°1
pandant que on charge les variables nécessaire a l'instruction N°2, l'instruction N°1 est executé
pandant que l'instruction N°2 est executé, on sauvegarde les variables uttilisé dans l'instruction N°1
puis on sauvegarde les variables uttilisé dans l'instruction N°2

la seul condition pour que ce système soit valable c'est que le chaque instruction qui se suivent n'uttilise pas les même registe/mémoire car sinon il faut attendre la phase "sauvegarde des variable de l'instruction N°1" avant d'effectuer "chargement des variable de l'instruction N°2"

comment s'appelle ce procédé? est ce que ça existe ou est ce que j'ai rêvé? est ce que j'ai raison de ne pas se faire suivre les instruction uttillisant les mêmes variable (dans la mesure ou ça reste possible) pour permettre ce système?

[edfed]

je t'invite à consulter la doc système intel pour plus de détails, et surtout, plus de vraies infos sur le sujet, pas des explications plus ou moins exactes issues d'une mémoire humaine, loin d'être infaillible.

je pense qu'après un idiv, ou un imul, il est uand meme preferable de n'utiliser le registre resultat qu'un certain nombre elevé d'instructions après.
pour le reste, pourquoi se prendre la tete sur ce genre de probleme, la lisibilité du code est plus importante que le gain de quelques nanosecondes, pour le moment. par la suite, avec un code bien validé, et déjà bien rapide, il est envisageable de passer du temps à melanger les instructions, tout en faisant des tests et des benchmark systematiquement...
une perte de temps impossible à compenser, meme après plusieurs siecles d'execution du programme, sur plusieurs milliers de machines. mais quand on aime, on ne compte pas.