subtilités du pipeline du 68000 - Page 1

bon, voilà, j'ai une petite question...

le pipeline du pentium permet d'exécuter une instruction FDIV, et en parallèle, pendant son exécution, d'autres instructions (à l'exception de IMUL) peuvent être exécutées...

si l'instruction suivant FDIV est une FP ou IMUL, toutes les instructions suivantes devront attendre la fin de l'exécution de FDIV...
si une FADD, FSUB ou FMUL est exécutée, il faudra attendre 3 cycles avant de pouvoir exécuter une nouvelle instruction.
et si l'instruction qui essaye d'obtenir le résultat est une FST en mémoire, il y aura un cycle de plus de perdu, soit 4 cycles...

ces subtilités permettent d'effectuer des optimisations assez intéressantes simplement en changeant l'ordre des instructions...

par exemple, si l'on effectue le calcul d'un produit vectoriel:

non optimisé:

fld [vec0+4] ;début & fin au cycle 0
fmul [vec1+8] ;début au cycle 1
fld [vec0+8] ;début et fin au cycle 2
fmul [vec1+4] ;début au cycle 3
;cycles 4-5 en attente
fsubrp st(1),st(0) ;début au cycle 6
;cycles 7-9 en attente
fstp [vec2+0] ;début au cycle 10
;fin au cycle 11
fld [vec0+8] ;début & fin au cycle 12
fmul [vec1+0] ;début au cycle 13
fld [vec0+0] ;début & fin au cycle 14
fmul [vec1+8] ;début au cycle 15
;cycles 16-17 en attente
fsubrp st(1),st(0) ;début au cycle 18
;cycles 19-21 en attente
fstp [vec2+4] ;début au cycle 22
;fin au cycle 23
fld [vec0+0] ;début & fin au cycle 24
fmul [vec1+4] ;début au cycle 25
fld [vec0+4] ;début & fin au cycle 26
fmul [vec1+0] ;début au cycle 27
;cycles 28 et 29 en attente
fsubrp st(1),st(0) ;début au cycle 30
;cycles 31-33 en attente
fstp [vec2+8] ;début au cycle 34
;fin au cycle 35
TOTAL: 36 cycles

optimisé:

fld [vec0+4] ;début & fin au cycle 0
fmul [vec1+8] ;début au cycle 1
fld [vec0+8] ;début & fin au cycle 2
fmul [vec1+0] ;début au cycle 3
fld [vec0+0] ;début & fin au cycle 4
fmul [vec1+4] ;début au cycle 5
fld [vec0+8] ;début & fin au cycle 6
fmul [vec1+4] ;début au cycle 7
fld [vec0+0] ;début & fin au cycle 8
fmul [vec1+8] ;début au cycle 9
fld [vec0+4] ;début & fin au cycle 10
fmul [vec1+0] ;début au cycle 11
fxch st(2) ;ne compte pas
fsubrp dt(5),st(0) ;début au cycle 12
fsubrp st(3),st(0) ;début au cycle 13
fsubrp st(1),st(0) ;début au cycle 14
fxch st(2) ;ne compte pas
;cycle 15 en attente
fstp [vec2+0] ;début au cycle 16
;fin au cycle 17
fstp [vec2+4] ;début au cycle 18
;fin au cycle 19
fstp [vec2+8] ;début au cycle 20
;fin au cycle 21
TOTAL: 22 cycles

22 vs 36, c bien...

bien évidemment, le 68000 n'est en aucun point comparable au pentium, surtout que les instructions ci-dessus s'appliquent à la virgule flottante, mais je me demandais si des subtilités d'optimisation en utilisant le pipeline du 68000 et suivant le même principe étaient possibles, ce qui serait tout de même assez intéressant...

[edit]Edité par sBibi le 08-11-2001 à 00:40:29[/edit]

Pour autant que je sache, le 68000 n'a aucun niveau de pipeline, donc n'a pas ce genre d'embrouille, mais c'est à confirmer.

Pipeline que récent

Le nombre de niveau indique le nombre d'opérations pouvant être décodées et analysées à l'avance - > récupération des données en mémoire. Protection classique contre le piratage. On modifie le programme 2 lignes plus loin. Le débugger plante, pas le prog.

Dès qu'il y a un saut, les pipelines doivent être vidés -> ralentissement. C'est une des raisons de la lenteur du P4 - 20 niveaux contre 10 au P3 -

pourtant je suis sur à 99.9% que le 68000 a un pipeline... tu me fais douter Miles...
(y a 0.1% d'incertitude... ce serait pas de po que ce soit ces 0.1% là )
...
une confirmation serait la bienvenue.
(et si oui, une réponse aussi...)

no,non, j'ai raison, il y en a un...

Ah oui ? c'est marqué où, pour voir ce qu'on peux en faire ?

Bon, j'ai vérifié sur le site de Motorola, et ils ne parlent pas d'un niveau de pipeline, mais ce qu'il disent c'est qu'il n'y a pas de cache de niveau 1, donc déjà pas de stockage des instructions à l'avance.

Vérification sur les autres 680X0 : il semble en avoir sur les versions supérieurs, mais pas sur la version de base ??
[edit]Edité par Miles le 08-11-2001 à 08:21:44[/edit]

Si il y a une mini pipeline : avant d'excuter reellement l'instruction en cours, et pendant qu'il la decode, il charge l'instruction suivante.
(Sur a 100
D'ou la seule optimisation de pipeline possible... qui s'apparente a des bredictions de branchements

Ex:
tst.w d0
beq.s toto
...
bra.s truc
toto:
...
truc:
C'est optimisable en determinant lequel est appelle le plus souvent. Si un branchement est 5x plus probableque l'tautre, ca vaut le coup.
Allez, reflechissez !

"il n'y a pas de cache de niveau 1, donc déjà pas de stockage des instructions à l'avance"

Je crois que tu confonds le cache et la prefetch queue. La dernière est la zone mémoire de quelques octets utilisée pour stocker la ou les instructions suivantes. C'est ce qui fait qu'en modifiant l'instruction placée juste après la courante, le changement n'est pas pris en compte.

Et je crois bien en effet que le 68000 a une pipeline, seulement comme elle n'a qu'un seul niveau, l'exécution en parallèle n'est pas possible. C'est vrai qu'à l'époque on ne aprlait aps encore trop de "pipeline" au grand public.

Si vous prenez un Z80 il n'y a pas de pipeline, c'est certain. Donc l'instruction suivante n'est décodée puis exécutée qu'après que la courante ait été entièrement traitée. En théorie, un seul niveau de pipeline permet quand même de décoder l'instruction suivante pendant que l'instruction courante est en cours d'exécution. Sur le 68000 je ne sais pas si c'est comme ça. A priori non...

Désolé, mea culpa !!

Mais c'est marqué où dans la doc ?

Miles>ben PpHd avait les 0.01% qui manquaient
PpHd>merci, je v réfléchir à ça calmement

Ca me dit quand même pas où c'est marqué...

bah, ça doit être perdu quelque part dans la doc de motorola...

a condition que ça y figure !

tt à fait... ils disent peut-être pas tout sur leurs processeurs

sBibi : il t'a couté combien ton livre ABRACH programmation graphique

rien du tt, c à la bibliothèque de ma fac

et pis, c abrash, pas abrach
[edit]Edité par sBibi le 09-11-2001 à 23:16:10[/edit]

de toute façob, les optimisation pour pentium (telles que celle concernant un hypothetique pipeline), ne peuvent au pire que ne rien changer sur la vitesse d'execution: donc il y a tout intret a les utiliser, hormis le fait que cela prend souvent du temps. Sur le 68000, les optimisations les plus utiles et presque perceptibles se situent au niveau des branchement conditionnels, comme l'a dit PpHd

PpHd>dc si j'ai bien compris, dans ton exemple, si le branchement vers toto est + probable que celui vers truc, on laisse comme ça:

tst.w d0
beq.s toto
...(1)
bra.s truc
toto:
...(2)
truc:

et si c truc ki est plus probable, fo mettre ça?

tst.w d0
bne.s truc
bra.s toto
toto:
...(2)
truc:
...(1)

c ça??
[edit]Edité par sBibi le 11-11-2001 à 02:54:41[/edit]

Non:
tst.w d0
bne.s pas_toto
...(2)
bra.s truc
pas_toto:
...(1)
truc:

argh,ok..., c bon... mais dans le cas où truc=pas toto, ma version marche qd même non?

Ta solution est fausse et inefficace (bra.s toto;toto: ...), désolé.

arf, vi, chuis con... c vrai... pas fé gaffe...

Non. Pas comme ca. Le bra.s truc final empeche tout gain :

cmp.w d0,d1
bne.s no_toto
...
Fin_de_toto
...

no_toto:
...
bra.s Fin_de_toto

Mais c'est plus efficase d'optimiser autres chose.

ué, kevin, t nul

PpHd>ok, merci
(pour ton mail aussi, je v tt refaire )

Au moins mon code fonctionne...

effectivement ca sera bien de savoir comment marche ce pipeline, et encore + de savoir ca longueure et oui + il est long + la ti sera rapide

court. Les 60 en ont un plus perfectionné, mais limite