[HELP] pour tester bug

[__sam__]

__sam__

#297715

Salut, j’utilise la dernière version de WinUAE 3.5.0 (2017.06.15) pour un projet sur amiga et je suis tombé sur un truc hyper curieux qui me fait tourner en bourrique depuis plusieurs jours.

Evidemment le bug s’est manifesté dans un project de plusieurs milliers de lignes et est très subtil (résultats de calculs numériques complètement faux). Au départ je pensais à un bug dans mon propre code, mais à force de travail j’ai réussi à isoler le bug dans un tout petit bout de C:[code]
#include <math.h>
#include <stdio.h>
double x = -6.5247e-09;
int main(int ac, char **av) {
double z = ceil(x);
double y = sin(x);
long *p = (void*)&y;
printf(“ceil(%g) = %g\n”, x, z);
printf(“sin(%g) = %g $%08x%08x\n”, x, y, p[0], p[1]);
return 0;
}
[/code]

Quand je compile avec pour le FPU 68k avec differents compilo (gcc, vbcc et sas/c), j’obtiens divers exe (cf ZIP joint.)

L’exe SAS/C marche impeccablement comme attendu et affiche toujours[code]
ceil(-6.5247e-09) = 0
sin(-6.5247e-09) = -6.5247e-09 $be3c05fbc7d1bb93
[/code]ce qui est correct.

En revanche les exe GCC et VBCC déconnent. L’exe GCC affiche toujours[code]
ceil(-6.5247e-09) = 0
sin(-6.5247e-09) = 0.0980171 $3fb917a6a04643d4
[/code] ce qui est incorrect (le sinus n’a pas le bon signe et est 10^7 fois plus grand que la valeur attendue). L’exe VBCC affiche aussi ce résultat erroné une 1ere fois, mais si on le relance il retombe sur celui correct de SAS/C les fois suivantes.

Je soupconne fortement l’émul FPU de UAE de déconner à plein tube quand on tripatouille ses bits de status (ce que fait GCC au moment du ceil pour faire un arrondi vers le haut). Mais pour en être sur il faut tester sur un vrai amiga. Or je suis à 800km des miens 🙁

Aussi je demande de l’aide à la communauté!

Pouvez vous télécharger le ZIP ci-joint (tst-fpu-1.zip, l’autre est à effacer mais je ne sais pas comment faire) et lancer les divers exe dans un CLI et dire si vous avec le résulat ok ou ko sur les divers cpu 68k possibles (à partir de 68030+68881) et les divers compilo. Cela me permettra de fournir un rapport de bug plus circonstancié. Si en plus vous avez de veilles versions de UAE vous pouvez voir si avec cette vieille version l’exe GCC affiche le résultat incorrect aussi. Ca permettra de cibler l’introduction du bug dans l’historique de WinUAE.

Merci par avance 🙂

___
PS: Chez moi le bug se produit avec toutes les combinaisons CPU/FPU/JIT/JIT+FPU. Donc ca n’est pas un pb de config UAE.

Attachments:

1. tst-fpu.zip
2. tst-fpu-1.zip

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.)

[bigdan]

bigdan

#297741

__sam__ : je regarde cela quand je rentre chez moi !

[seg]

seg

#297744

Lancé sur mon 060 (avec Oxyron Patcher):

18.Ram Disk:> tst.gcc.881.exe
ceil(-6.5247e-09) = 0
sin(-6.5247e-09) = -6.5247e-09 $be3c05fbc7d1bb92

18.Ram Disk:> tst.sasc.881.exe
ceil(-6.5247e-09) = 0
sin(-6.5247e-09) = -6.5247e-09 $be3c05fbc7d1bb93

18.Ram Disk:> tst.vbcc.881.exe
ceil(-6.5247e-09) = 0
sin(-6.5247e-09) = -6.5247e-09 $be3c05fbc7d1bb8c

[__sam__]

__sam__

#297747

ok sur 060 les résultats sont tous identiques. Ca semble bel et bien indiquer un soucis subtil avec l’émul FPU de WinUAE qui affecte spécialement GCC…

Chose étonnante: les derniers bits affichés en hexa sont differents, preuve que fsin ne marche pas pareil suivant les compilo.

Au fait tu connais une bonne doc sur le 060 qui décrit la façon de bien utiliser le superscalar ?

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.)

[Bwah Bwah]

Bwah Bwah

#297749

Tu as testé avec la dernière béta WinUae ?

Il y a eu pas mal de modifs dessus.

Edit, je viens d’essayer et la valeur semble correcte pour tst.vbcc. ??

Cela ne passe pas avec gcc parce que ma version de ixeemul est trop ancienne.

Edit 2 : Ne pas tenir compte de mon edit, j’étais en 68040. :p

[__sam__]

__sam__

#297765

Elle se trouve où la beta de WinUAE ? Sur http://www.winuae.net/download/ je ne vois rien.

[EDIT] C’est ici que ca se passe: http://www.emu-france.com/news/49548-ordi-winuae-public-beta-v3-4-1-beta-8-fr/

Et effectivement le bug a l’air d’avoir disparu. Je check avec mon gros projet … (compilation en cours) … ok bug disparu!

Par contre l’émulation fpu est un chouia plus lente. J’ai 91fps sur le wb là où avant j’avais 98.

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.)

[Bwah Bwah]

Bwah Bwah

#297768

Euh non c’est une vieille béta que tu as :p

La dernière béta est là :

http://www.winuae.net/files/b/winuae_3600b7.7z

Depuis la b1, quelques soucis concernant le FPU ont été corrigés. Je n’ai pas tout mis.

– Softfloat fix: 68040+ will convert unnormal zeros (zero mantissa, non-zero exponent) to normals without datatype exceptions.-

– 68040/060 without FPU: many FPU instructions generated incorrect F-line stack frame contents, usually wrong PC or EA field.

– 68881/68882 FMOVECR undocumented ROM offsets are now 100% accurately emulated, offsets 0x40-0x7f return f-line exception.-

Host FPU mode: set host FPU round to nearest mode temporarily (if needed) before calling any native C-library trigonometric functions, other rounding modes can return (very) wrong results.

[__sam__]

__sam__

#297771

Host FPU mode: set host FPU round to nearest mode temporarily (if needed) before calling any native C-library trigonometric functions, other rounding modes can return (very) wrong results.

Bingo, c’est exactement ce genre de soucis. C’est un very wrong result avec les fonctions trigo.

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.)

[Aladin]

Aladin

#297772

Winuae 3.6.0 beta 7 en FR
http://www.tradu-france.com/index.php?page=fullstory&id=496

[seg]

seg

#297778

@sam
J’ai jamais trouvé aucune bonne doc pour les optims 060.

Au mieux, ce genre de truc: http://tict.ticalc.org/docs/68k_optimize.txt

Sinon, t’as regardé mes benchs avec ton quake?

[__sam__]

__sam__

#297780

Les benchs ? ah non. Tu fais bien d’attirer mon attention là dessus, je viens d’y poster une réponse. Ton retour m’est très utile, car il met en exergue un bug dans le core 080. Visiblement en ce moment je suis à fond dans les bugs d’implémentations de CPU réels (le thread vampire) et virtuels (ce thread) 🙂 🙂 🙂

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]

flype

#297792

J ai testé pour vérification les binaires des 2 archives sur la vampire+fpu/femu. Pas de bugs. Les résultats sont tous corrects.

https://usercontent.irccloud-cdn.com/file/FBKncXI2/image.png

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

[__sam__]

__sam__

#297794

Oui, apparemment c’est un bug sur la dernière version de winUAE. La future 3.6 ne l’aura plus car les beta ne montrent plus le bug.

Au fait, de ton coté, c’est quoi les documents que tu utilises pour optimiser du code asm pour 080?

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]

flype

#297795

Le 080 se code comme le 060, tout en ayant toutes les instructions du 040.
Ensuite il faut avoir l’esprit que tout se fait en un cycle la plupart du temps, voir moins (fuse/bond => voir avec gunnar). Le reste c’est l’AMMX, c’est tout un chapitre en soit, pas le temps là je pars bosser :p

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

[__sam__]

__sam__

#297796

Bon taf alors 🙂

Apparemment les docs pour coder efficacement sur 060 sont légères sur le net. Celle qu’a indiqué seg me parait d’ailleurs bizarre car ils disent par exemple que sur 060 (tout comme 030),
[code]
moveq.l #20,d0
add.l d0,d1
[/code]
est mieux que
[code]
add.l #20,d0
[/code]
alors que j’ai cru comprendre que sur 080 la 2e version est mieux car elle fait tout sur une seule instruction (Gunnar m’a indiqué que les “long” operation prennent toutes 1 seul cycle.)

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.)