Pipelines PPC !

In article <f1092b0f.0307260216.44cb61b9@posting.google.com>,
johndillingerfr@yahoo.fr (John Dillinger) wrote:

Yo à tous !


Je voudrais avoir quelques précisions sur le fonctionnement des
pipelines sur 603e ou 604e (et même d'autres PPC, le principe doit
être grosso-modo le même).
La doc d'IBM sur le 604e n'est pas très clair je trouve.

Petit exemple:

(1) add
(2) div
(3) add

(1) est passé dans la SCIU et (2) dans la MCIU. Et ensuite, que ce
passe-t-il pour (3) ?

Le cpu bloque en attendant la fin de (2) pour charger (3) dans la SCIU
?

(3) va etre dispatche dans la SCIU a condition qu'il n'y ait pas de
dependance entre (2) et (3). Ceci dit, un blocage va intervenir dans
la Completion Queue : tout ce qui suit (2) ne pourra pas etre retire
tant que le div ne sera pas termine, ce qui induit rapidement un
blocage du dispatching (remplissage de la Completion Queue).

John Dillinger wrote:

Sinon la doc du 604e par IBM ne contient pas toutes les mnémoniques
(lis et mr n'y sont pas, par exemple).

Je vais peut être dire une connerie, mais il me semble que mr n'est pas
une mnémonique du PPC, mais un "alias" pour un "or".
Soit: "mr rA,rS" est équivalent à "or rA,rS,rS"

Pour cela, voir:
http://www.eecs.umich.edu/~stever/373/appendixf.pdf

--
Stephane

John Dillinger <johndillingerfr@yahoo.fr> wrote:

héhé, Didier Levet, pas trop nostalique de ton précédent computer ?
...........

Sinon la doc du 604e par IBM ne contient pas toutes les mnémoniques
(lis et mr n'y sont pas, par exemple). Tu connais une doc qui les as
toutes ? Je vais jeter un oeil sur celles du G3 et G4 de ce pas
d'ailleurs...


A+

Tu peux voir là, il y a beaucoup de doc faut chercher :

<http://www.lightsoft.co.uk/Fantasm/fant.html>


--
Le sage montre la lune, l'imbécile regarde le doigt.

In article <f1092b0f.0307290556.18778867@posting.google.com>,
johndillingerfr@yahoo.fr (John Dillinger) wrote:

héhé, Didier Levet, pas trop nostalique de ton précédent computer ?

Ca depend des jours :)

(1) add
(2) div
(3) add

(3) va etre dispatche dans la SCIU a condition qu'il n'y ait pas de
dependance entre (2) et (3). Ceci dit, un blocage va intervenir dans
la Completion Queue : tout ce qui suit (2) ne pourra pas etre retire
tant que le div ne sera pas termine, ce qui induit rapidement un
blocage du dispatching (remplissage de la Completion Queue).

Oui, pas de dépendance d'écriture. En supposant qu'on est sur un 603e,
(3) est tout de même executé (car 3 pipelines sur 603e) pendant le
calcul de (2) ou le cpu attend vraiment la toute fin du div ?

(1) et (2), ou (2) et (3) vont etre dispatchees en meme temps compte
tenu qu'il n'y a pas de dependances. Dans les deux cas, les instructions
(1) et (3) vont etre terminees bien avant le div, si bien que seul le
premier add pourra etre retire de la Completion Queue (Completion Unit).
Lorsque le div sera termine, (2) et (3) seront retirees de la CQ en
meme temps.

Je demande ça, car toute l'organisation des mnémoniques en dépends: il
faut donc regrouper les ménmos selon leurs appartenances à telle ou
telle unité pour obtenir les meilleurs perfs. Si la réponse est non à
ma question, le code doit devenir (1) (3) (2), c'est mieux.

Ce depend de ce que tu as avant. S'il s'avere que (1) est retiree de
la CQ avec l'instruction precedente, le code actuel fonctionne tout
a fait bien. En revanche, si (1) est retiree seule, il vaut mieux
utiliser la seconde solution (2 add puis le div).

J'ai aussi lu que les store en load pouvaient s'executer par 2 en 1
cycle avec 3 pipelines, tu confirmes bien ? Il faut donc grouper tant
que faire se peut ces 2 mnémos. Mais que se passe-t-il pour:

Il n'y a qu'une seule LSU, donc ca m'etonnerai que deux instructions
puissent etre executees simultanement.

Sinon la doc du 604e par IBM ne contient pas toutes les mnémoniques
(lis et mr n'y sont pas, par exemple). Tu connais une doc qui les as
toutes ? Je vais jeter un oeil sur celles du G3 et G4 de ce pas
d'ailleurs...

Ce sont des pseudo-instructions, reconnues par l'assembleur, mais
qui correspondent a des instructions documentees plus complexes (il
s'agit en fait de formes simplifiees). Par exemple, "mr rA,rB"
correspond a "ori rA,Rb,0" (ou quelque chose commme ca).

héhé, Didier Levet, pas trop nostalique de ton précédent computer ?

Ca depend des jours :)

Ben c'est toujours autant la discorde sur ton ancienne plateforme...
J'essaie de motiver, d'expliquer, de monter un groupe qui bossent à un
but commun, mais je me heurte à des murs d'incompréhension... Enfin
bref...

(1) add
(2) div
(3) add

(1) et (2), ou (2) et (3) vont etre dispatchees en meme temps compte
tenu qu'il n'y a pas de dependances. Dans les deux cas, les instructions
(1) et (3) vont etre terminees bien avant le div, si bien que seul le
premier add pourra etre retire de la Completion Queue (Completion Unit).
Lorsque le div sera termine, (2) et (3) seront retirees de la CQ en
meme temps.
Ce depend de ce que tu as avant. S'il s'avere que (1) est retiree de
la CQ avec l'instruction precedente, le code actuel fonctionne tout
a fait bien. En revanche, si (1) est retiree seule, il vaut mieux
utiliser la seconde solution (2 add puis le div).

Non, simplifions: ya rien avant. C'est le début de la routine.
Je débute en asm PPC, et je veux prendre les bonnes habitudes dès le
début, et j'ai un gros handicap, mon english n'est pas super bon...
Les docs me sont difficiles à bien comprendre !

Et visiblement, j'ai pas encore bien pigé le fonctionnement de la CQ.
L'exemple que j'ai donné contient 2 mnémos type SCIU et 1 type MCIU.
Le 603e possède 3 pipelines.
Les unités (LSU, MCIU, SCIU...) peuvent donc sans problèmes opérer sur
chacun des 3 pipelines indépendement (pas comme sur le 060) ?
Et quand un pipeline et l'unité MCIU sont busy par le div, les 2
autres pipelines continuent à fonctionner. Il faut donc bien organiser
les mnémos SCIU et MCIU.

Il n'y a qu'une seule LSU, donc ca m'etonnerai que deux instructions
puissent etre executees simultanement.

Oui, c'est logique, mais j'avais vu quelques lignes que je ne retrouve
pas... Je vais continuer à chercher.

Ce sont des pseudo-instructions, reconnues par l'assembleur, mais
qui correspondent a des instructions documentees plus complexes (il
s'agit en fait de formes simplifiees). Par exemple, "mr rA,rB"
correspond a "ori rA,Rb,0" (ou quelque chose commme ca).

Ah d'accord !




Sinon, meci aux deus autres personnes qui m'ont répondu, je vais jeter
un oeil.


A+

héhé, Didier Levet, pas trop nostalique de ton précédent computer ?

Ca depend des jours :)

Ben c'est toujours autant le désordre sur ton ancienne bécanne.
J'essaie de motiver, d'expliquer de monter un groupe pour bosser à un
but commun, mais je tombe sur des murs d'incompréhension.... Enfin
bref...

(1) add
(2) div
(3) add

(1) et (2), ou (2) et (3) vont etre dispatchees en meme temps compte
tenu qu'il n'y a pas de dependances. Dans les deux cas, les instructions
(1) et (3) vont etre terminees bien avant le div, si bien que seul le
premier add pourra etre retire de la Completion Queue (Completion Unit).
Lorsque le div sera termine, (2) et (3) seront retirees de la CQ en
meme temps.
Ce depend de ce que tu as avant. S'il s'avere que (1) est retiree de
la CQ avec l'instruction precedente, le code actuel fonctionne tout
a fait bien. En revanche, si (1) est retiree seule, il vaut mieux
utiliser la seconde solution (2 add puis le div).

Simplifions: ya rien avant, c'est le début de la routine. Mais
qu'arrive-t-il si une autre mnémo de type MCIU survient ? Là, il vaut
mieux mettre les deux add entrent les deux MCIU, non ? L'execution du
code va continuer (ya 2 pipelines de libre encore) jusqu'à ce que le
code rencontre une éventuelle dépendance d'écriture (auquel cas il
bloque) ?

Il n'y a qu'une seule LSU, donc ca m'etonnerai que deux instructions
puissent etre executees simultanement.

J'avais lu quelques lignes que je retrouve pas. Je vais continuer à
chercher.

Ce sont des pseudo-instructions, reconnues par l'assembleur, mais
qui correspondent a des instructions documentees plus complexes (il
s'agit en fait de formes simplifiees). Par exemple, "mr rA,rB"
correspond a "ori rA,Rb,0" (ou quelque chose commme ca).

Ah ok.


Merci aux deux autres personnes qui m'ont répondus, je vais jeter un
oeil.



A+

In article <f1092b0f.0307301037.13660eb3@posting.google.com>,
johndillingerfr@yahoo.fr (John Dillinger) wrote:

Non, simplifions: ya rien avant. C'est le début de la routine.
Je débute en asm PPC, et je veux prendre les bonnes habitudes dès le
début, et j'ai un gros handicap, mon english n'est pas super bon...
Les docs me sont difficiles à bien comprendre !

Ca a beau etre en anglais, il n'y a rien de tres complique (1)

Et visiblement, j'ai pas encore bien pigé le fonctionnement de la CQ.
L'exemple que j'ai donné contient 2 mnémos type SCIU et 1 type MCIU.
Le 603e possède 3 pipelines.
Les unités (LSU, MCIU, SCIU...) peuvent donc sans problèmes opérer sur
chacun des 3 pipelines indépendement (pas comme sur le 060) ?
Et quand un pipeline et l'unité MCIU sont busy par le div, les 2
autres pipelines continuent à fonctionner. Il faut donc bien organiser
les mnémos SCIU et MCIU.

Ne melange pas tout. Je vais essayer de t'expliquer ca simplement
(quitte a prendre quelques libertes).

Pour shematiser, le CPU est compose d'un pipeline d'entree, suivi de
plusieurs unites de calcul fonctionnant en parallele (chacune disposant
de son propre pipeline), elles-meme suivies d'un dernier pipeline (en
l'occurence, la Completion Unit).
Le pipeline d'entree sert a lire les instructions depuis le cache et
se termine au niveau de l'etage de dispatching. A ce niveau, au maximum
2 instructions sont envoyees dans 2 unites de calcul differentes (603e,
G3 ou G4 premier du nom). Du coup, chacune de ces deux instructions se
retrouve dans un nouveau pipeline : celui de l'unite de calcul. Les
instructions progressent alors dans leur pipeline respectif jusqu'a
atteindre la Completion Unit.

Si tu cherches a obtenir les performances maximales, il faut tenir
compte de la totalite du pipeline, et pas seulement de ce qui se passe
au niveau de chaque unite. Lorsque les instructions sont dispatchees
(une ou deux, a chaque cycle), une entree leur est allouee dans la
Completion Queue (qui compte 6 entrees sur le 603e, sauf erreur).
Lorsque cette table est pleine, le dispatching est bloque.

C'est precisement ce qui se passe avec un div, par exemple. Puisqu'il va
falloir plusieurs cycles pour l'executer, l'entree correspondante dans
la Completion Queue va rester allouee a cette instruction tant que la
division ne sera pas terminee. Et comme ces entrees sont liberees dans
l'ordre de leur allocation (pile FIFO), et au maximum par 2, cette
fameuse division va interdire la liberation des entrees plus recentes
(donc des instructions qui suivent le div).
Si on reprend ton exemple, le premier add va quitter la CQ au bout d'un
cycle, mais le second ne pourra etre retire qu'avec le div, et pas avant.
Ca veut dire qu'apres le div, seules 4 ou 5 instructions pourront etre
dispatchees (au maximum).

Le point bloquant est bel est bien cette fameuse Completion Unit. Son
fonctionnement fait qu'une instruction prenant beaucoup de temps
provoque tres rapidement un blocage du dispatching (pile FIFO pleine) et
que le temps perdu ne se rattrape pas (2 instructions, au mieux, sont
dispatchees a chaque cycle, et 2 instructions, au mieux, sont retirees
de la CQ a chaque cycle). Au passage, note que le meme "probleme" se
retrouve sur G3/G4/G5.
Par consequent, le mieux est encore d'equilibrer les temps d'execution
de chaque paire d'instructions, si c'est possible, de facon a exploiter
au mieux cette faiblesse en evitant de bloquer inutilement la CQ. On
peut aussi regrouper plusieurs instructions lentes (avec eventuellement
une seule instruction rapide entre chaque) pour limiter le nombre de
blocages. On peut aussi profiter de la "lenteur" d'une instruction pour
dispatcher, en meme temps, une instruction soumise a une dependance.


(1) hmmm... Tout compte fait, meme en francais ce n'est pas si simple ;-)