Logicielsmoto.com

Nous sommes le 28 Mar 2024, 11:26

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 35 messages ]  Aller à la page Précédente  1, 2, 3
Auteur Message
MessagePosté: 07 Sep 2022, 16:06 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
ça ressemble à un changement de palette en cours de ligne non ?
C'est pour pouvoir afficher les 16 couleurs sélectionnées et conserver les couleurs de l'outil sur la partie haute j'imagine.

Pour ceux qui veulent poursuivre sur l'histoire des changements de palette je propose d'aller ici :
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=684&p=7938#p7937

comme ça on peut poursuivre sans polluer le fil de TEO.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 18 Déc 2022, 22:48 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Hum, je pense être tombé sur un bug d'émulation.

Avec la diskette ci-jointe
Fichier(s) joint(s):
disk.zip [118.46 Kio]
Téléchargé 107 fois
j'ai un programme qui donne ceci avec DCMoto à l'écran et sur l'imprimante:
Code:
Found 30x16k free memory
Loading 0:dhryston.bin...done


Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute

Execution starts, 10 runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:            5
        should be:   5
Bool_Glob:           1
        should be:   1
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       7
        should be:   7
Arr_2_Glob[8][7]:    20
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:          27832
        should be:   (implementation-dependent)
  Discr:             0
        should be:   0
  Enum_Comp:         2
        should be:   2
  Int_Comp:          17
        should be:   17
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:          27832
        should be:   (implementation-dependent), same as above
  Discr:             0
        should be:   0
  Enum_Comp:         1
        should be:   1
  Int_Comp:          18
        should be:   18
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           5
        should be:   5
Int_2_Loc:           13
        should be:   13
Int_3_Loc:           7
        should be:   7
Enum_Loc:            1
        should be:   1
Str_1_Loc:           DHRYSTONE PROGRAM, 1'ST STRING
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           DHRYSTONE PROGRAM, 2'ND STRING
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

User time: 1600000
Microseconds for one run through Dhrystone: 160000
Dhrystones per Second:                      6
VAX MIPS rating * 1000 = 3
C''est le résultat attendu.

En revanche avec TEO_WIN_187_BETA3_20220907, on obtient ceci
Code:
Found 30x16k free memory
Loading 0:dhryston.bin...done


Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute

Execution starts,  runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:           
        should be:   
Bool_Glob:           
        should be:   
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       
        should be:   
Arr_2_Glob[8][7]:   
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:         
        should be:   (implementation-dependent)
  Discr:             
        should be:   
  Enum_Comp:         
        should be:   
  Int_Comp:         
        should be:   
  Str_Comp:          %s
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:         
        should be:   (implementation-dependent), same as above
  Discr:             
        should be:   
  Enum_Comp:         
        should be:   
  Int_Comp:         
        should be:   
  Str_Comp:          %s
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           
        should be:   
Int_2_Loc:           
        should be:   
Int_3_Loc:           
        should be:   
Enum_Loc:           
        should be:   
Str_1_Loc:           %s
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           %s
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

User time:
Microseconds for one run through Dhrystone: 
Dhrystones per Second:                       
VAX MIPS rating * 1000 = 
On constate que l'affichage du printf (ah oui j'ai oublié de signaler que c'est du code C) n'est pas bon. Les chiffres sont vides, et les %s affichent %s au lieu de l'argument du printf. Pire: le calcule part en boucle après le "VAX MIPS rating *1000 =".

Comme c'est du C qui prends de longues minutes et plein de cycles, il est difficile de savoir quelle instruction se comporte différemment entre les deux émulateurs. Cependant, je vais essayer de creuser.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 18 Déc 2022, 23:13 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Samuel Devulder a écrit:
Cependant, je vais essayer de creuser.
Ok, il semblerait que le code suivant ne se déroule pas pareil entre TEO et DCMoto:
Code:
   1301        77DF               opLESSTHANOREQUAL
   1302  5+1   77DF EC   42          LDD   2,U <== D=$0000 CC=Z
   1303  6+1   77E1 A3   46          SUBD  6,U <== D=$FFB7 CC(teo)=E+N CC(DCMoto)=E+N+C
*** DIVERGENCE!!!
   1304  5+1   77E3 ED   46          STD   6,U
   1305  5+0   77E5 EC   C4          LDD   ,U
   1306  4+1   77E7 33   44          LEAU  4,U
   1307  4+1   77E9 A2   41          SBCA  1,U
   1308  4+0   77EB E2   C4          SBCB  ,U
   1309  3     77ED 2D   33          BLT   outTRUE ; $7822
   1310  3     77EF 2E   18          BGT   outFALSE ; $7809
   1311  4+1   77F1 AA   42          ORA   2,U
   1312  4+1   77F3 AA   43          ORA   3,U
   1313  3     77F5 26   12          BNE   outFALSE ; $7809
   1314  3     77F7 20   29          BRA   outTRUE ; $7822
En effet il apparait une divergence en $77E1.

Sous DCMoto la carry=1, mais elle vaut 0 sous TEO. Comme on calcule un 0 - $49, on devrait avoir la carry à 1 à l'issu de l'opération. Or elle est affichée à 0 sous TEO, ce qui est erroné.

Note: MESS donne aussi une carry=1 juste après le SUBD.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Déc 2022, 11:34 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Je ne pige pas ce comportement sous TEO avec le code asm suivant:
Code:
   LDD  #0
   SUBD #$49
Fichier(s) joint(s):
image_2022-12-19_112642239.png
image_2022-12-19_112642239.png [ 196.88 Kio | Vu 2369 fois ]
Fichier(s) joint(s):
Commentaire: D=0, CC=EFIZ
Ca va je suis d'accord.

image_2022-12-19_112720543.png
image_2022-12-19_112720543.png [ 197.5 Kio | Vu 2369 fois ]
Fichier(s) joint(s):
Commentaire: D=$FFB7, CC=EFIN.
Mais où est passée la carry=1 ? BUG!

image_2022-12-19_112835028.png
image_2022-12-19_112835028.png [ 197.21 Kio | Vu 2369 fois ]

Or le code C est le suivant: https://sourceforge.net/p/teoemulator/c ... 809.c#2555
Code:
static void subd(void) {    /* NxZxVxCx */
    /* compute address */
    if (step<0x21) compute_address();
    switch (step) {
    /* [Data High : EA] */
    case 0x21 : value=LoadByte(address)<<8;
                break;
    /* [Register Low : EA] */
    case 0x22 : value|=LoadByte(address+1);
                break;
    /* [Don't Care] */
    case 0x23 : dr=(ar<<8)+br-value; /* DR = $FFFFFFB7 */
                m1=ar; m2=(-value)>>8;
                ar=dr>>8;  /* AR =$FFFFFFFF */
                br=dr&0xff; /* BR=$B7 */
                ovfl=res=sign=ar; /* RES=$FFFFFFFF */
                res|=br; /* RES=$FFFFFFFF, et donc Carry=(RES&0x100 !=0) == 1 */
                ar&=0xff; /* AR = $FF */
                step=0;  /* reset fetch */
                break;
    }
Ya un truc qui ne colle pas entre ce que j'observe dans le débugger et ce que le code C est supposé faire.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Déc 2022, 19:31 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Oh zut, je me suis focalisé sur le mauvais lièvre. En fait la GUI du débuggeur de TEO n'affiche pas le bit C alors qu'il est présent (CC=$D9 est impair) sur la dernière capture. :beuh: :oops:

Bon par contre ca veut dire que
Code:
   SBCB  1,U
   SBCA  ,U ; A=$FF CC(teo)=$8B CC(dcmoto)=$89
   BLT   outTRUE
   BGT   outFALSE
ne fonctionne pas pareil entre DCMoto/Mess et TEO. En effet, sous TEO après le SBCA, on a CC=$8B alors que sous DCMoto CC=$89. La différence entre les deux est que TEO positionne V=1 contrairement à DCMoto et MESS.

Le code du SBCA pour TEO est celui-ci: https://sourceforge.net/p/teoemulator/c ... 09.c#l2163
Code:
        value=LoadByte(address); /* value = 0 */
        m1=ar; m2=-value; /* ar = 0; m1 = 0; m2 = 0; */
        ar-=value+((res&0x100)>>8); /* ar = -1 */
        ovfl=res=sign=ar; /* ovfl=res=sign = -1 */
        ar&=0xff; /* ar = 255 */
Un truc me turlupine: pourquoi m2 = -value sans tenir compte de la retenue ? La soustraction sur ar c'est avec value+((res&0x100)>>8), donc logiquement il faudrait soustraire ((res&0x100)>>8) aussi à m2. La différence entre les émulateurs vient peut-être de là.

Si je regarde un implémentation indépendante des SBCA/B, par exemple celle-ci: https://github.com/maly/6809js/blob/mas ... 9.js#L1319
Code:
  var oSBC = function (b, v) {
    var temp = b - v - (CC & F_CARRY);
    //temp &= 0xff;
    CC &= ~(F_CARRY | F_ZERO | F_OVERFLOW | F_NEGATIVE);
    CC |= flagsNZ[temp & 0xff];
    if (temp & 0x100) CC |= F_CARRY;
    setV8(b, v, temp);
    return temp & 0xff;
  };
Examinons ce qu'il se passe. On calcule temp = b - v - retenue = 0 - 0 - 1 = -1. Ok, ensuite ca calcule les flags N, Z et C dont on se fiche. Le calcul de V se fait dans setV8
Code:
setV8 = function (a, b, r) {
    CC |= ((a ^ b ^ r ^ (r >> 1)) & 0x80) >> 6;
  };
en l'occurrence ici on a: a=0, b=0, et r=-1 donc "a ^ b ^ r ^ (r >> 1)" = "0 ^0 ^ -1 ^ (-1>>1)" = "0^0^-1^-1" = 0. On ne devrait donc pas positionner V d'après ce simulateur 6809 en JS.

Voyons ce qu'il se passe si, dans teo, on mettais la retenue dans le calcul de m2. C'est à dire, qu'on calcule m2 = -value - ((res&0x100)>>8) = 0 - 1. Donc
Code:
V= (!((m1^m2)&0x80))&&((m1^ovfl)&0x80)
== (!((0^-1)&0x80)) && ((0^-1)&0x80)
...
== (!(0x80)) && (0x80)
== (!true) && true
== false
Humm on dirait que ce coup-ci V=0. C'est la bonne valeur !

Ca semble être un bon candidat au bug.

Ce qui m'ennuie c'est que ADCA/ADCB ont le même défaut (m2 ne tient pas compte de la retenue), et que surtout ce code est super super vieux (de Marcel-O-5 au moins) et que personne n'est tombé sur ce bug avant. Bon, après, il faut peut-être être un tordu comme moi pour faire de l'arithmétique multi-précision sur 8bits pour le découvrir...

Gilles: tu en penses quoi ?

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 35 messages ]  Aller à la page Précédente  1, 2, 3

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 20 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com