Infos sur la Vampire
-
Tient, petite question con du jour :
Actuellement, dès qu’on veut faire un bench d’un Amiga, on continue de le faire avec un Sysinfo que la plupart reconnaissent comme n’étant plus vraiment aussi parlant et pertinent qu’avant.Il y aurait un super ch’tit codeur motivé de génie qui saurait nous refaire un outil équivalent qui saurait prendre en compte les architectures plus moderne et sachant les reconnaitre (avec pourquoi pas leur révision) et les exploiter à fond qu’on puisse avoir des chiffres plus parlant et surtout voir les apports réels de chaque processeur ou carte accélératrice installé (PPC et 68080 de la Vampire compris) ?
En fait c’est compliqué de benchmarker une machine. On peut tester la vitesse des instructions arithmétiques, logiques, virgule flottantes, les accès en mémoire (tableaux), et un mix de tout qui soit réaliste. Ca donne AIBB, mais ce dernier souffre du fait qu’on a pas un score global qui résume le tout. En outre il date un peu et n’a pas de versions optimisée pour le superscalaire (060 et au delà).
Si on veut plus moderne, il y a minibench: http://minibench.apollo-accelerators.com/, et si on veut comparer avec d’autres machines, le bon vieux dhrystrone: http://aminet.net/package/util/moni/Dhrystone11
Pour tester la mémoire, il y a le test « stream », https://www.cs.virginia.edu/stream/
M’enfin quoi qu’on en dise, Sysinfo est la référence sur amiga. Il permet de comparer les différentes machines avec un vieux programme pas spécialement optimisé pour leur CPU, ce qui est le cas de la plupart des programmes aminet. Finalement, malgré ses défauts, on revient toujours à Sysinfo. Je rigole même de voir que les détracteurs de Sysinfo (je pense à Gunnar en particulier) persistent à poster des photos de sysinfo en lieu et place de leur propre benchmark (minibench) quand ils évaluent une machine. Bref, Sysinfo c’est LE standard sur amiga. Tout le monde le possède, et tout le monde peut le lancer rapidement sur sa machine pour la comparer aux autres.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)@flype
Moi ce qui me chagrine un peu, c’est ce changement de nom de registre avec les e0-7. Motorola avait eu l’intelligence de nommer ses registres d0-7. La logique voudrait que l’extension du nombre des registres porte les noms d8-15.
Je peux comprendre qu’il y ait une divergence de nom si les registres n’ont pas la même fonction ou la même taille, mais ce n’est pas ce que j’ai cru comprendre. Moi j’ai compris que tous les registres étaient maintenant 64 bits et utilisables avec n’importe quelle instruction, sans distinction (hormis les registres d’adresse plus particuliers).Un exemple tout bête, pour empiler tous les registres, il faudrait écrire movem d0-d7/e0-e7,-(sp) au lieu de movem d0-d15,-(sp). C’est balo.
Donc, l’utilisation du mnémonique load au lieu de move pour un mode immédiat, je peux à la rigueur le comprendre sémantiquement même si c’est pas dans l’usage motorola, mais le changement de nom des registres, ça je comprends pas. Ça me fait penser au micmac des noms de registres sur x86 alors qu’il n’y a pas besoin de faire ça sur 68k vu que le nommage est déjà prévu pour être étendu.
Bref, j’ai besoin d’infos pour comprendre l’esprit.
seg: c’est pas un soucis ca l’écriture ASM. A la limite tu n’as qu’à faire
[code]
#define D8 E0
#define D9 E1
…
#define D15 E7
[/code]
et là tu peux utiliser « moveq #0,D15 » si ca te chante. Perso j’aime pas que D15 soit plus long à écrire que E7. En outre avec les registres Ei et Bj, on sait que ce sont des regs spéciaux pas sauvés par défaut dans les fonctions C d’un compilo pas adapté et même peut-être pas sauvés en cas de context-switch, mais je pense que l’OS est patché pour ca, sinon ca planterait dès que 2 progs AMMX tournent ensemble.Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)@__sam__
Même avec les macros, tu ne peux pas écrire movem D0-D15.
Cet exemple est purement indicatif. Il ne faut pas réduire ma question à celui-ci.Sinon, à ce que j’ai lu, ils ont patché l’OS pour empiler tous les registres en 64 bits. Ce n’est pas un soucis vu qu’on a le même problème avec ou sans registres fpu. Problème déjà résolu par Commodore.
De plus, savoir qu’E0 à E7 sont des registres spéciaux, c’est aussi frappant que D8-D15. Pas besoin de changer de lettre pour ça. Et, effectivement, je n’ai pas parlé des registres Bx qui me posent le même soucis sémantique.
Dans l’absolu, c’est juste un problème d’assembleur. Il suffirait qu’il accepte les 2 syntaxes et tout le monde est content.
Question con: es-tu sur que tu peux empiler tous les 32 regs avec un seul movem D0-D15/A0-A15 ? l’opcode 68000 de movem attends un argument sur 16 bits après, or 16 bits c’est juste ce qu’il faut pour le bitmask D0-D7/A0-A7. Si ca se trouve pour empiler E0-E7/B0-B7 il faut faire un 2e movem avec un autre opcode indiquant qu’on s’addresse aux regs supplémentaires, non ?
Plus généralement parlant, c’est pareil pour les bits indiquant les addresses via des registres. Il y a tout juste de la place pour écrire (Dx.L*4,Ay). Si on veut faire pareil avec Ey il faut un autre argument 16 bits que celui standard. Ca vient peut-être de là la distinction D/E et A/B. Avec D et A, c’est l’encodage 68000. Mais pour E et B, c’est un autre encodage de l’adresse qui est utilisé.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
@seg
Comme l’a dit _sam_, tu ne peux pas ré-utiliser le même encodage que le 68000 pour movem. L’opcode pour movem n’aurait pas la place pour accueillir de nouveaux bits pour les registres étendus.Après bon, c’est un choix, E comme Etendu, ou E comme ce qui suit D. Et B comme ce qui suit A pour les registres d’adresses/mémoires.
Et de même tu ne pourrais pas inclure Dn/An dans un nouveau MOVEM(2) car çà consommerait encore 8+8 bits. Une solution consiste à utiliser les RegFiles avec Load/Store, j’en reparlerai bientôt.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.@sam et flype
Oui, on peut empiler les 15 registres données et adresses en même temps sur 68k.
Quant au fait que l’instruction movem soit « limitée » en nombre de bits, ce n’est pas le problème. D’ailleurs, toutes les instructions move n’ont pas le même opcode. Elles ont juste le même mnémonique. C’est l’assembleur qui fait le travail pour restituer les bons codes dans l’exe.
Ca peut être idem avec un movem étendu qui serait capable d’empiler les anciens comme les nouveaux registres. On peut imaginer un movem spécial nouveaux registres également. Bref, c’est l’assembleur qui choisit le bon opcode.
@seg, oui çà je suis d’accord mais ça ne résout pas le problème si tu souhaitais (ce que je comprenais) mixer les registres legacy et les nouveaux du genre MOVEM.L D2-D14/A2-A6/A8-A15 à moins que le compileur en déduise tout seul les 2 x MOVEMs à générer (MOVEM.L D2-D7/A2-A6 + MOVEM2.L D8-D14/A8-A15).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Allez un petit test de brilliance avec le chipset SAGA affichant du HAM8 sur A600
Ca marche pas mal. Merci Jesus 🙂
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)@seg transformer un movem, cad une seule instruction, en deux movem (deux instructions) c’est pas trop le boulot d’un assembleur. C’est le boulot d’un optimisateur de type peephole (cf POPT sur aminet 🙂 )
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)On peut jouer à comment faire compliquer quand on peut faire simple bien sûr, mais c’est pas mon trip.
L’instruction move sur 68k est peut-être celle qui possède le plus d’opcode différents. Pourtant, l’assembleur nous simplifie le job en utilisant qu’un seul mnémonique. D’ailleurs il n’y a pas beaucoup de codeurs qui utilisent le mnémonique movea par exemple. C’est l’assembleur qui fait le job.
Enfin je dis ça, il n’y a pas mort d’homme bien sûr.
Encore une nouvelle avancée au niveau de FEmu. Gunnar vient d’annoncer qu’ils dépassent allégrement celle du 040 et sont voisin de celle du 060, et ce ci sur toutes les vampires 2 (x11): http://www.apollo-core.com/knowledge.php?b=2¬e=8898&z=omg1Jf
(à venir avec le core 2.7 sans doute)Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)Infos venant de Gunnar:
« Avec un code adapté, le fpu embarqué du 68080 peut atteindre le même score MFlop qu’un 68060 à 500 mhz.
Alors que le 68060 nécessite 3 cycles pour une instruction FPU, le FPU de l’Apollo peut résoudre/exécuter 2 instructions flottantes par cycle plus un FMOVE. Donc, par cycle, l’Apollo a un FPU 7 fois plus rapide que celui du 68060.
L’Apollo offre de nouvelles options de codage. Tandis que les anciens 68k avaient seulement 8 registres FPU, le 68080 en offre 32. Ceci permet de coder bon nombre d’algorithmes plus facilement. »Je pense que la comparaison est faite entre le 68060 et le Cyclone 5.
L’augmentation du nombre de registres permet également de gagner des cycles dans les algos par rapport au 060. J’espère qu’il va les appeler fp8 à fp31 😉
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire
