1

Comme je sais qu'il y a pas mal de personne qui traine sur ce forum qui connaissent le 68k,
je voulais savoir si vous n'aurais pas ou connaitrais pas un programme en 68k qui permettrais de tester toutes ces fonctionnalités (genre tester les muls, les divisions, les additions/soustractions, etc... avec les différents mode d'adressage) afin de vérifier qu'il fonctionne correctement ?

Merci happy
avatar

2

Tu veux vérifier un émulateur en fait ? Ou un assembleur ? Ou un vrai proc ?
Sinon, je ne connais pas de tel programme, mais la doc de Motorola spécifie les instructions avec tous leurs modes d'adressages. Faut aussi penser à vérifier le SR si c'est dans le cas d'un ému.
Après, c'est facile, mais probablement fastidieux d'écrire un tel programme avec la doc...
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

3

(il en a refait un from scratch happy)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

4

Si HW3Patch fonctionne, ton émulation du 68000 d'origine est très bonne. smile
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

Rien ne dit que son émulateur est un émulateur de TI tu sais ?

./1 > Notre cher KK fait référence à ça : http://pasti.fxatari.com/68kdocs/68kPrefetch.html
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

6

Pour le coup ce n'est pas pour reproduire le fonctionnement d'une TI, mais d'une machine plus féline cheeky
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7

il me semble qu'il y avait un outil d'autotest qui incluait le CPU (sur amiga ?), une espèce d'ancètre de benchmark
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

8

Y'a des tests de CPU inclus au boot oui, mais ils ne testent généralement que des trucs fondamentaux, ils sont loin d'être exhaustifs.

Je sais que des jeux de tests existent pour les assembleurs (des sources qui utilisent toutes les variantes de toutes les instructions possibles), mais je ne sais pas si on en trouve pour les CPU eux-mêmes.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

Folco (./2) :
Tu veux vérifier un émulateur en fait ? Ou un assembleur ? Ou un vrai proc ?
Sinon, je ne connais pas de tel programme, mais la doc de Motorola spécifie les instructions avec tous leurs modes d'adressages. Faut aussi penser à vérifier le SR si c'est dans le cas d'un ému.
Après, c'est facile, mais probablement fastidieux d'écrire un tel programme avec la doc...

Comme le dit Zerosquare, j'ai réécrit un core 68000 en VHDL sur FPGA. tongue

J'ai des bugs étrange avec certains programmes et vu la taille et la complexités des programmes impactés, c'est quasi impossible de localiser l'endroit où ça ne fonctionne pas correctement.
De plus je ne suis pas certain que c'est le core 68k qui en est la cause, du coup si je pouvais vérifier que je n'ai plus de bugs dans mon implémentation des instructions du 68k c'est que les bugs viennent d'ailleurs smile
j'avais déjà fait plus ou moins un programme de test pour dégrossir mais pour tester l'ensemble des instructions avec leur variantes c'est....chiant à coder cheeky
avatar

10

Clair ^^

Faudrait faire l'inverse d'un assembleur en fait : un moteur qui, à partir d'un opcode et des modes d'adressages autorisés, des longueurs des opérandes, écrive et exécute pour chaque instruction un panel de tout ce que l'instruction peut faire, et vérifie que ça fonctionne comme attendu.
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

11

C'est assez compliqué à faire en fait, car tu dois utiliser un jeu d'instructions très réduit pour tester chaque instruction, afin de minimiser au plus la possibilité de double-bug, qui introduirait énormément de faux positifs.
En gros, il te faut des instructions "fiables", que tu pourras si possible auto-tester au début de ton programme. En principe, chaque instruction validée peut ensuite être utilisée dans les tests suivants, mais si tu veux faire un test global qui teste toutes les erreurs d'un coup, tu ne peux pas faire cela.

Typiquement, tu pourras envisager de représenter le résultat de chaque test par une valeur non nulle en mémoire, donc il faudra que tu aies au moins une instruction d'écriture en mémoire qui soit 100% fiable. Evidemment, il te faudra une instruction d'initialisation de registre 100% fiable, ainsi qu'une instruction d'addition ou de soustraction 100% fiable, et il te faudra une instruction de saut conditionnel 100% fiable (tu choisis un seul flag) pour tes boucles et tes tests.

Ça doit être assez intéressant à coder comme programme, mais sacrément fastidieux. Et je ne suis même pas sûr que ça puisse être auto-généré…
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

12

GoldenCrystal (./5) :
./1 > Notre cher KK fait référence à ça : http://pasti.fxatari.com/68kdocs/68kPrefetch.html

Pas seulement. Il y a aussi les bits inutilisés du SR.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

13

Il faut aussi voir comment sélectionner les tests. Même pour un simple add.l d0, d1, y'a 264 cas possibles...
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

14

Ben, un test exhaustif testerait les 2⁶⁴ combinaisons possibles pour s'assurer qu'elles sont toutes parfaitement gérée.
Il y a sans doute plusieurs façons de procéder pour parvenir à ce résultat :
1. Tu peux recourir à un observateur externe (i.e. un logiciel qui tourne sur PC) pour analyser les résultats d'addition (incluant les flags) et les valider par rapport à un calcul de référence.
2. Tu peux réduire le test à un nombre fini mais potentiellement important de cas.
3. Tu peux calculer un hash relativement simple (mais pas trop quand même) des résultats + valeur des flags sur la totalité des 2⁶⁴ cas, et le comparer à un hash de référence.

La seule méthode parfaitement fiable est la 1, à supposer que tu aies un moyen de communication fiable (validé) entre ton CPU et ton observateur externe (et que l'observateur externe n'induise pas d'effet quantiques sur ton CPU observé cheeky). Sinon, pour obtenir un résultat approximativement aussi juste, il faut sans doute une combinaison des méthodes 2 et 3…

(Dans tous les cas, il ne faut pas se foirer sur le calcul de référence, bien entendu cheeky)

./12 > Ah oui, peut-être. Mes souvenirs sont assez vagues à ce niveau cheeky
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

15

Oui mais justement, même avec la méthode 3, 264 c'est bien trop grand pour être faisable en un temps raisonnable. Et là on ne parle que d'une seule version d'une seule instruction !

Donc il faut forcément utiliser la méthode 2, mais la question est : comment choisir les cas ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

16

Bah dans le cas de l'addition, tu peux sans doute réduire ton jeu de test à cette liste :
• Pour chaque bit, tester le cascading de l'addition (i.e. 01+01 -> 10, pour ceux qui ne verraient pas de quoi je parle)
• Pour toutes les chaines continues de bits 1 possibles, tester le cascading de l'addition. (e.g. 011 + 001 -> 100, 01110 + 00010 -> 10000, …)
• Pour chaque octet (de 0 à 3) parmi les 4, somme de [tous les entiers de 00 à FF] avec [tous les entiers de 0 à FF].
• Plus ou moins la même chose en sommant des valeurs où des octets indépendants sont définis (e.g. 0055 + 4A00 -> 4A55). L'opération doit produire le même résultat qu'un OR.

Et à chaque test, tester que les flags sont bien modifiés de la façon dont on s'y attend…

Ça fait toujours un grand nombre d'opérations, mais ça devient beaucoup plus gérable.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes