Mystere du 68000, partie 1 - Page 1

Chers auditeurs, je vous remercie de me rendre visite dans cette section reserve aux mysteres du 68000. Nous allons donc commencer par reflechir sur un mystere profond du 68000... Mystere mysterieux. Sans aucune explication semble-t-il.
Vous etes motives ? Ca tombe bien, vous allez pouvoir reflechir ! Et en plus, c'est une ligne qui revient tres souvent lors de l'affichage de graph, qui pourront donc etre optimises...
Etes-vous pret ?
C'est parti !
Examinez les 2 codes suivants :

and.l d5,(a2)
or.l d4,(a2)

Et
move.l (a2),d3
and.l d5,d3
or.l d4,d3
move.l d3,(a2)

Il n'y a rien de mysterieux semblerait-il !

Ah ah !
mesurez la difference de bench entre ces 2, et regardez bien.
Ce n'est pas tres visible, mais il y a une petite difference de l'ordre de 3%. (je ne sais plus, mais c'est pas lourd). Elle est toujours mesuree, et il semble qu'il n'y ait pas d'erreur du au demarrage du comptage.
Or elle est inexepliquable en comptant les cycles, et il n'y pas de cache.

D'ou peut-elle venir ?

les ingenieurs de motorola on laissez une erreur ou c toi

c zerb???
en fait je sais pas comment on compte les cycles mais je fait confiance à pphd, donc c'est bizarre
(au fait c'est un quizz dont tu connait les réponses ou tu fait cela pour nous chambouler la tête )

etrange..

Genlib : tellement fort que ça optimise même le processeur

tu vx dire kil y a une difference entre ces 2 morceaux ???? apparemment non ça fait la mm chose....
bah c le 68000....et c lequel le + rapide avec le comptage ?

tu veux nous faire croire que les 4 lignes vont en gros aussi vite que seulement 2 ???
(c moi qui suis détraqué ou ...)

Ça arrive plusieurs fois. Mais ici, selon PpHd, les 4 lignes seraient plus rapides que les 2 lignes alors qu'en théorie le nombre de cycles devrait être le même.

Mais je ne pense pas que gaspiller 4 octets en taille de code et 1 registre vaille le coup pour une optimisation qui en théorie ne devrait rien changer. Surtout que ça peut très bien varier selon l'exemplaire individuel du processeur.
[edit]Edité par Kevin Kofler le 16-10-2001 à 22:10:19[/edit]

#paranormal# ?

lol !
c vrai ke c bizzare !

Une supposition : le fait d'avoir un nombre d'instruction différent dans une boucle, fait varier la façon dont se remplira la prefetch queue du processeur ; au moment de boucler, le proc doit vider cette queue, or dans un cas elle sera déjà vide (parce que, mettons, les dernières instructions de la boucle tenaient pile dedans), et dnas l'autre il restera quelque truc, auquel cas le proc perdra du temps à la vider...
Sauf qu'à priori la prefetch n'intervient pas dans le comptage des cycles.
Bon j'ai encore dit une connerie moi non ?

Ou bien le circuit interne effectuant l'opération est un peu plus complexe et demande plus d'énergie chauffe et vas moins vite ?

>Blue_z: Le prechargement de l'instruction ne peut pas intervenir.
>Kevin: Je demande une explication.
>Vil: Non
>frekazoid: mesure.

Bon moi j'ai une theorie, mais bon, j'attends les votres.

Non, je pense qu'il est juste. Sinon c quand meme etrange que le and.l d5,(a2) soit aussi rapide. Il y a une bonne optimisation de la part de motorola. (i.e. c plus rapide que de faire : lect mem 2cycles, trait 2 c, ecri 2c => 6 c // faux 5 c : read wl 1, trait wl +read wh 1, trait wh+write wl 1 , write wh 1 : 4 cycles).

Voici une modeste tentative d'explication, Maître :

Le contrôleur vidéo de la TI68k monopolise le bus de données et le bus d'adresses tous les 4 (je ne suis pas sûr de cette valeur mais ça ne change rien à la validité de l'explication) cycles d'horloge.
Le code n°1 nécessite que ces bus soient libres tous les 20 cycles (chaque instruction demande 20 chs donc elles sont séparées de 20 chs)
Le code n°2 nécessite que ces bus soient libres tous les 28 cycles (les 3 premières instructions demandent 28 chs donc les 2 move sont séparées de 28 chs)

Statistiquement il est clair que le code n°1 devra plus souvent "attendre" la libération des bus que le code n°2

Donc ça serait un effet sur HW1 seulement?

Sur HW2 aussi le contrôleur doit lire dans le buffer situé en $4C00 !?

Non, c'est fait lors des écritures en cette adresse, pas en permanence, sur HW2.

C'est mis à jour aussitôt ou il attend quelques cycles histoire que 3840 octets ne soient pas recopiés à chaque fois qu'on allume un pixel ?

Chaque écriture écrit à la fois dans la RAM et dans la mémoire vidéo. Ce n'est pas l'écran entier qui est recopié lors d'une écriture, mais juste le mot (word) auquel on écrit.

L'incrémentation de pc est plus lente dans certains cas ?

Un bon moyen de verifier l'hypothese de Thibaut est de le tester sur HW2.

En plus, Thibaut a une HW2

c passionant, tout ça !
moi, sans rien savoir, j'aurais supposé que tout les n cycles, y auvait un recopiage de tout l'écran, mais je pb, c que la ram serais inacessible pendant toute la lecture du buffer vidéo !
et vu que ça fait pas de problèmes apparants, j'ai bien pensé que c'était pas ça !
c quand même bien fait !

C'est pour ça qu'un sprite s'affiche plus vite ?

PpHd, Kevin, ... ça m'étonne que vous n'ayez pas vu que ma démonstration n'est valable que si l'on prend les bouts de codes sans les répéter !!
Voici ce que je traçais hier soir dans mon lit pour m'apercevoir que ma solution est erronée :

(j'ai une écriture de porc je sais)

Comme moi, vous voyez bien que le move de fin (de la première fois) est immédiatement suivit du move de début (de la seconde exécution)... Donc ces 2 moves consécutifs (qui durent 12 cycles), font que la "distance" moyenne entre 2 moves est de (28+12)/2= 20 cycles : comme pour le code n°1 !
Nous sommes toujours sans réponse
[edit]Edité par Thibaut le 18-10-2001 à 18:07:57[/edit]

J'ai aussi pensé à cela un moment, puis j'ai pensé que non, ça n'intervient pas, mais en effet ça intervient. Et en effet, c'est bizarre.

Une idée: le rafraichissement de l'écran aurait-il une période d'environ 21 ou 22 cycles et prendrait-il 1 ou 2 cycles? Ce qui ferait que pour la première boucle, après la première collision, le code, après avoir attendu 1 ou 2 cycles, et s'être exécuté pendant 20 cycles tomberait en collision à chaque fois au cycle 21 ou 22, alors que pour la 2ème boucle, après une collision, la prochaine lecture de l'écran se trouverait au cycle 21 ou 22 et celle d'après au cycle 42 ou 44, alors que les lectures en mémoire du code sont aux cycles 29 ou 30 et 41 ou 42, et donc il n'y a pas d'autre collision...
Cette hypothèse pourrait être vérifiée en rajoutant des nops en des endroits stratégiques pour les 2 boucles.
[edit]Edité par Kevin Kofler le 18-10-2001 à 21:32:36[/edit]

et moi !

Je trouve que votre idee est bien. Personnellement j'ai une autre idee. Mais elle est peut etre moins bien. J'attends la preuve (Test sur HW).

Bah c'est pas compluiqué. Lit mon explication calmement.

Kevin : alors je me serait trompé en croyant m'être trompé () ??
PpHd : c'est quoi ton explication ?