Vitesse du 68000 - Page 1

Bonsoir,
Je suis désolé, je ne savais pas trop où poster mon topic.
J'ai essayé de me mettre un peu à l'asm (avec AS, en regardant le code généré par CC ). J'ai ensuite voulu tester les temps de cycle du processeur à travers une boucle. Mais là j'ai été surpris par les résultats: je trouve que certaines instructions font 20 cycles et plus!
Alors je me demandais, les temps de cycle semblent bien multipliés par 4 non? Et est-ce toujours le cas sur les hardwares utilisant ce processeur?
Aussi, lorsque je compare ce qu'il est possible sur TI et ce qui se faisait (pour ne citer qu'elles) sur Mega Drive ou Neo Geo (AES), je me demande où est la différence quand même...
1) Est-ce que je programme si mal, ce qui expliquerait tout?
2) Est-ce que la TI est réellement 4x moins performante que ces consoles?
Si je prends le mode 7 (software) de l'écran titre de Sonic CD (MegaCD, le sub-68k est à 8 ou 12 MHz) c'est d'un tout autre niveau que nos mode 7 à nous sur TI: c'est bien plus fluide (~20 fps je crois), ça prend 256x96 et c'est en full-précision.
Parce que si je prends mon Sonic, il tourne bien à 16 MHz (ARM), mais j'imagine pas le faire tourner à 8/4 = 2 MHz (Mega Drive)... (par contre à 8 MHz à la limite oui).
Merci d'avance pour vos explications

Sur les consoles de jeux c'est rarement le CPU qui travaille pour l'affichage, tout est acceleré par des circuits spécialisés.

Bah déjà le 68000 de la TI est à au plus 12MHz, ensuite (et surtout), les consoles ont un hardware dédié au graphisme, comprendre: une interface écran adaptée, et surtout des cartes d'affichage, de la meilleure mémoire, etc. Bref c'est pas vraiment comparable (d'ailleurs la même remarque s'appliquerait à la megadrive, qui ayant le même processeur est vraiment moins puissante que la neogeo )

Merci.
Pour ce qui concerne le circuit graphique, je vois la différence, mais ce n'est pas si flagrant (comparable au temps dépensé sur TI pour un moteur N/B, sauf que le rendu est infiniment plus beau). Par contre vous ne savez pas ce qu'il en est du 68000 lui-même (en dehors des graphismes)? Est-ce que j'ai mal mesuré?

Ximoon :
Bah déjà le 68000 de la TI est à au plus 12MHz, ensuite (et surtout), les consoles ont un hardware dédié au graphisme, comprendre: une interface écran adaptée, et surtout des cartes d'affichage, de la meilleure mémoire, etc. Bref c'est pas vraiment comparable (d'ailleurs la même remarque s'appliquerait à la megadrive, qui ayant le même processeur est vraiment moins puissante que la neogeo )

Et justement c'est plutôt l'inverse: la TI n'a aucun waitstate (temps d'attente pour un accès à une mémoire) alors que les consoles oui, donc la TI devrait égaler / surpasser ces consoles (pour un même rendu en software).

1- tu as mesuré comment ?
2- j'ai pas bien compris à ce que tu as voulu dire par "les temps de cycle semblent bien multipliés par 4 non?"
3- tous les timings sont disponibles sur le net, entre autres dans la doc constructeur
4- il y a effectivement des instructions qui prennent plus de 20 cycles, ça arrive souvent dans certains cas d'adressages mémoires. Une division peut même dépasser la centaine de cycles !

Ximoon :
2- j'ai pas bien compris à ce que tu as voulu dire par "les temps de cycle semblent bien multipliés par 4 non?"

Que les nb de cycles sont pour une bonne partie multiple de 4 (mais pas tous, certaines instructions sont multiples de 2), et que meme l'addition la plus simple fait 4 cycles ? Mais effectivement la formulation "les temps de cycle semblent bien multipliés par 4 non?" est perfectible...

Enfin de la meme maniere que "l'unité de taille d'acces memoire" est 16 bits, "l'unite de temps" pourrait etre 4 cycles (meme si au niveau hard l'unite de temps est bien 1 cycle et pas 4)

1) Une boucle en décrémentation. Je vois qu'elle prend X temps pour Y itérations. Je rajoute une instruction au milieu et je regarde la différence
2) Dans mes tests, la plupart des instructions 8 bits testées faisaient 4 ou 8 cycles (sauf erreur). Et en 16 bits, c'est pire encore. Le 68k de la TI a un pipeline?
3) Je suis pitet pas sur la bonne doc parce que je trouve pas
4) Oué ok mais bon la division elle est hors jeu (je parlais de simples move.x, add.x, lsl, pea, etc.)

Faut dire que vu que c'est pas pipeliner, on peut calculer facilement la durée en cycles d'une fonction, quelque part on a de la chance ^^

Pollux
:

Ximoon :
2- j'ai pas bien compris à ce que tu as voulu dire par "les temps de cycle semblent bien multipliés par 4 non?"

Que les nb de cycles sont pour une bonne partie multiple de 4 (mais pas tous, certaines instructions sont multiples de 2), et que meme l'addition la plus simple fait 4 cycles ? Mais effectivement la formulation "les temps de cycle semblent bien multipliés par 4 non?" est perfectible...

Enfin de la meme maniere que "l'unité de taille d'acces memoire" est 16 bits, "l'unite de temps" pourrait etre 4 cycles (meme si au niveau hard l'unite de temps est bien 1 cycle et pas 4)

Justement, alors TOUS les 68k ont une "unité de temps" de 4 cycles?

Brunni :
1) Une boucle en décrémentation. Je vois qu'elle prend X temps pour Y itérations. Je rajoute une instruction au milieu et je regarde la différence
2) Dans mes tests, toutes les instructions 8 bits testées faisaient 4 ou 8 cycles (sauf erreur). Et en 16 bits, c'est pire encore. Le 68k de la TI a un pipeline?
3) Je suis pitet pas sur la bonne doc parce que je trouve pas
4) Oué ok mais bon la division elle est hors jeu (je parlais de simples move.x, add.x, lsl, pea, etc.)

1- sur une échelle de combin de temps ?
2- pour une instruction possédant un mode 8 bits et un mode 16 bits, le temps d'exécution reste le même
3- http://www.ticalc.org/pub/text/68k/timing.txt
4- pourtant pas compliqué

Brunni> je pense que oui au moins pour les 680[012]0...

Ximoon> y a qd meme du prefetch (et j'avais commencé a essayer de comprendre les timing *exacts*, mais c'est vraiment affreux... des fois tu perds/gagnes des cycles [enfin, pas des cycles entiers, c'est ca qu'est bizarre : enfin ca doit etre des cycles entiers, mais qui arrivent de facon non-deterministe, et comme on n'a pas de compteur de cycles, on est obligé de faire des moyennes sur bcp de lancements, donc c'est impossible a mesurer sans oscillo ], je sais pas si ca vient du bus ou d'autre chose) (alors que sur Athlon, c'est bien plus déterministe malgré le pipeline, et on a vraiment un nombre rigoureusement exact de cycles tant qu'on reste dans le cache )

1) Environ deux secondes par test.
2) Oui c'est vrai, pardon. C'est en 32 bits que c'est infiniment plus lent.
3) J'avais bien celui là (mais bon j'ai pas le courage de tout lire, j'ai juste fait une recherche "cycle" mais ça n'a rien donné de satisfaisant...)

(bah nan, de 2 cycles)
Pour le préfetch, c'est pas seulement les intructions de saut qui le rendent non déterministe comme tu dis ? T'as corrélé avec la taille des instructions exécutées j'imagine ?

THE reference sur les timings, c'est la doc de motorola (68kUM je crois, a moins que ca soit 68kPM)

Brunni :
1) Environ deux secondes par test.
2) Oui c'est vrai, pardon. C'est en 32 bits que c'est infiniment plus lent.
3) J'avais bien celui là (mais bon j'ai pas le courage de tout lire, j'ai juste fait une recherche "cycle" mais ça n'a rien donné de satisfaisant...)

3- bah que demander de plus ?

Pollux :
THE reference sur les timings, c'est la doc de motorola (68kUM je crois, a moins que ca soit 68kPM)

Je sais pas j'ai la version papier made by SGS Thompson

Pollux> re- Alors il me reste vraiment du chemin à faire
Par contre je ne comprends toujours pas l'histoire du mode7 software de la Mega CD qui est plus performant que sur TI... à ton avis ça vient de quoi? (et en plus l'accès à la VRAM dans ce mode est largement plus compliqué & lent pour la Mega Drive)...

Ximoon :
(bah nan, de 2 cycles)
Pour le préfetch, c'est pas seulement les intructions de saut qui le rendent non déterministe comme tu dis ? T'as corrélé avec la taille des instructions exécutées j'imagine ?

Nan mais c'est vraiment incompréhensible, meme en changeant pas le code qui est "pres" des sauts, le fait d'intervertir deux instructions peut changer le timing (meme si y a pas d'interdépendences...)

Ximoon
:

Brunni :
1) Environ deux secondes par test.
2) Oui c'est vrai, pardon. C'est en 32 bits que c'est infiniment plus lent.
3) J'avais bien celui là (mais bon j'ai pas le courage de tout lire, j'ai juste fait une recherche "cycle" mais ça n'a rien donné de satisfaisant...)

3- bah que demander de plus ?

Heu ben en fait savoir par exemple qu'un add.w fait X cycles, j'arrive pas à trouver ça... (il y a tout sur la syntaxe, l'adressage, la modification du sr mais pas cette info là)

Brunni :
Par contre je ne comprends toujours pas l'histoire du mode7 software de la Mega CD qui est plus performant que sur TI... à ton avis ça vient de quoi? (et en plus l'accès à la VRAM dans ce mode est largement plus compliqué & lent pour la Mega Drive)...

bah deja c'est plus simple en 256 couleurs, mais c'est sur que si ils ont réussi a faire 12000000/20/256/96 = 24 cycles par pixel, c'est vraiment pas mal du tout (perso la version qui etait dans mes cartons est censé tourner dans les 30-35 cycles par pixel, mais avec plus de 5 cycles en plus a cause du fait que c'est pas du 256 couleurs)

Brunni
:

Ximoon
:

Brunni :
1) Environ deux secondes par test.
2) Oui c'est vrai, pardon. C'est en 32 bits que c'est infiniment plus lent.
3) J'avais bien celui là (mais bon j'ai pas le courage de tout lire, j'ai juste fait une recherche "cycle" mais ça n'a rien donné de satisfaisant...)

3- bah que demander de plus ?

Heu ben en fait savoir par exemple qu'un add.w fait X cycles, j'arrive pas à trouver ça... (il y a tout sur la syntaxe, l'adressage, la modification du sr mais pas cette info là)

tu confonds pas avec le 68kguide ?

Pollux: pas tout lu mais

http://www.cse.dmu.ac.uk/~bb/Teaching/ComputerSystems/WorkStations/WorkStations.htm a dit:

.1 Prefetch and Pipelining
A program consists of a sequence of instructions in main memory. Under the control of the Control Unit each instruction is processed in a cyclic sequence called the fetch/execute or instruction cycle:
Fetch Cycle

A machine code instruction is fetched from main memory and moved into the Instruction Register, where it is decoded.
Execute Cycle
The instruction is executed, e.g. data is transferred from main memory and processed by the ALU.
To speed up the overall operation of the CPU modern microprocessors employ instruction prefetch or pipelining which overlap the execution of one instruction with the fetch of the next or following instructions. For example, the MC68000 uses a two-word (each 16-bits) prefetch mechanism comprising the IR (Instruction Register) and a one word prefetch queue. When execution of an instruction begins, the machine code operation word and the word following are fetched into the instruction register and one word prefetch queue respectively. In the case of a multi-word instruction, as each additional word of the instruction is used, a fetch is made to replace it. Thus while execution of an instruction is in progress the next instruction is in the prefetch queue and is immediately available for decoding. Powerful processors make extensive use of pipelining techniques in which extended sequences of instructions are prefetched with the decoding, addressing calculation, operand fetch and execution of instructions being performed in parallel (Stallings 2000). In addition, modern processors cater for the pipelining problems associated with conditional branch instructions. For more details see http://www.cs.herts.ac.uk/~comrrdp/pipeline/pipetop.html and http://www.cs.umass.edu/~weems/CmpSci535/535lecture8.html

16 couleurs, pas 256 (ce serait trop facile )

ah tiens ticalc interdit les liens direct vers un .txt ? c'est "timing.txt" qu'il faut choisir...

Pollux
:

Brunni
:

Ximoon
:

Brunni :
1) Environ deux secondes par test.
2) Oui c'est vrai, pardon. C'est en 32 bits que c'est infiniment plus lent.
3) J'avais bien celui là (mais bon j'ai pas le courage de tout lire, j'ai juste fait une recherche "cycle" mais ça n'a rien donné de satisfaisant...)

3- bah que demander de plus ?

Heu ben en fait savoir par exemple qu'un add.w fait X cycles, j'arrive pas à trouver ça... (il y a tout sur la syntaxe, l'adressage, la modification du sr mais pas cette info là)

tu confonds pas avec le 68kguide ?

nan, j'aime bien celu ilà qui s'imprime plus vite (je sais pas s'il est 100% exact par contre mais je pense que oui)

Pollux :
ah tiens ticalc interdit les liens direct vers un .txt ? c'est "timing.txt" qu'il faut choisir...

ah très juste j'avions pas fait gaffe dsl

Ximoon :
Pollux: pas tout lu mais

Mouais, c'est pas vraiment le probleme ici : justement, c'etait des instructions qui etaient "loin" des branch...

Menfin bon il faudrait que je me replonge dedans, en fait ^^

Ximoon
:

Pollux :
tu confonds pas avec le 68kguide ?

nan, j'aime bien celu ilà qui s'imprime plus vite (je sais pas s'il est 100% exact par contre mais je pense que oui)

je parlais a Brunni, pas a toi, bouffon ©

Pollux
:

Brunni :
Par contre je ne comprends toujours pas l'histoire du mode7 software de la Mega CD qui est plus performant que sur TI... à ton avis ça vient de quoi? (et en plus l'accès à la VRAM dans ce mode est largement plus compliqué & lent pour la Mega Drive)...

bah deja c'est plus simple en 256 couleurs, mais c'est sur que si ils ont réussi a faire 12000000/20/256/96 = 24 cycles par pixel, c'est vraiment pas mal du tout (perso la version qui etait dans mes cartons est censé tourner dans les 30-35 cycles par pixel, mais avec plus de 5 cycles en plus a cause du fait que c'est pas du 256 couleurs)

Comme dit plus haut, c'est du 16 couleurs
5 cycles? Alors toutes les instructions ne sont pas alignées à 2/4 cycles?

-