Connexion avec TiEmu - Page 14

Martial Demolins (./388) :
Euh... encore ... euh... un feature report
Je suis en train de déboguer. Quand j'arrive à l'instruction à $7edde, le Z-flag n'est pas mis. Ok, je veux tester avce Z=1.
Je coche donc la case comme on voit ici :

C'est un bogue dans la 3.01, c'est corrigé dans la 3.01a déjà, je n'ai juste pas voulu mettre à jour le RPM (8 heures de compilation pour la version x86_64 dans QEMU) juste pour ça. (Tous les autres correctifs dans la 3.01a sont spécifiques à un certain système d'exploitation provenant de Redmond.)

Pourquoi est-ce parfaitement voulu?

Ce n'est pas voulu, c'est bien un bogue, et il est déjà corrigé dans le SVN.

Tu as pu avancer ton Tétris ?

> (8 heures de compilation pour la version x86_64 dans QEMU)
Ouch, 8h... Tu n'utilises pas kqemu, qui est maintenant sous GPL ?
Et le _virtualiseur_ VirtualBox Open Source Edition (GPLv2) ne serait pas plus rapide que QEMU, qui reste quand même un _émulateur_ ?

Lionel Debroux (./394) :
> (8 heures de compilation pour la version x86_64 dans QEMU)Ouch, 8h... Tu n'utilises pas kqemu, qui est maintenant sous GPL ?

kqemu ne peut pas accélérer l'émulation x86_64 sur un système 32 bits.

Et le _virtualiseur_ VirtualBox Open Source Edition (GPLv2) ne serait pas plus rapide que QEMU, qui reste quand même un _émulateur_ ?

Et VirtualBox non plus.

Pour émuler une architecture différente, c'est forcément une émulation entièrement logicielle. Et je ne compilerais pas sous QEMU si c'était la même architecture!

Ah oui, on dirait que je ne suis pas bien réveillé
J'ai une machine x86-64, sur laquelle SabayonLinux x86-64 tourne à merveille, mais je n'ai pas actuellement de Fedora dessus: j'attends Fedora 8, dans un peu plus de deux semaines s'ils sont à temps. Je ne prends pas les Test car je n'ai pas envie de télécharger un ISO complet à chaque fois, ça serait bien qu'ils fournissent des patches xdelta (plus efficace que rsync, il me semble...), comme SimplyMEPIS en a pris l'habitude.
Peut-être passerai-je un jour à un kernel et des applications x86-64 sur SimplyMEPIS.

Tu peux mettre à jour les paquetages avec yum ou apt sans passer par l'ISO aussi. Et ils travaillent sur des DeltaRPMs qui seront des xdeltas de RPMs pour des mises à jour avec moins à télécharger.

./398: je le sais, mais apt et yum ne sont pas utiles pour avoir un ISO destiné à être seedé sur BT, ce que j'ai fait avec FC5 et FC6 (plus de 50 Go). C'est pour pouvoir seeder sur BT qu'il me faudrait un truc du genre patch xdelta pour l'ISO

Martial, j'ai finalement changé de stratégie pour la news de cette semaine. Au lieu de faire un combo "jeux de Tetris" j'ai fait un combo "jeux de l'été". On annoncera ton Tetris dans une news rien qu'à lui dès qu'il sera prêt, ok ?

C'est normal que mon programme aille beaucoup plus vite que la normale quand il tourne sur TIEmu ? "Restrict to actual speed" est bien coché.
Mon programme est inutilisable : quand on appuie sur une touche ça fait comme si j'appuyais 50 fois. Tout défile à fond la caisse. Comme il se sert de boucle vides pour se temporiser, j'imagine que le 68000 émulé effectue largement plus de 12 millions de cycles par seconde.

Ca va être corrigé ?

Non, je régule en me basant sur le fait que le processeur tourne à 12 MHz environ
L'AI5 est désactivée et la routine de gris est sur l'AI1.

Thibaut (./404) :
Comme il se sert de boucle vides pour se temporiser

Tu es sûr que tes boucles restent après optimisation ?

le programme en question c'est Einstein ? si oui, pour quelle raison faut-il le temporiser ? (c'est seulement pour le délai de répétition entre deux touches ?)

Martial Demolins (./403) :
On n'a pas accès au menu contextuel quand le débogueur est ouvert. Certaines exceptions provoquent automatiquement l'ouverture du débogueur. On ne peut donc pas quitter TiEmu lors de certains bogues. On est obligé de killer.C'est voulu?

Il y a une fonction du menu qui fonctionne à débogueur ouvert, c'est "Reset calculator", c'est ça qu'il faut utiliser dans ce cas (tu peux faire un revert ensuite si tu as un état enregistré valide).

Thibaut (./404) :
C'est normal que mon programme aille beaucoup plus vite que la normale quand il tourne sur TIEmu ? "Restrict to actual speed" est bien coché.

Ce n'est pas normal, normalement "Restrict to actual speed" veut dire ce que ça veut dire. Je sais que le comptage des cycles n'est pas parfait à l'heure actuelle, mais pas à ce point!

Ca va être corrigé ?

Peut-être. Au minimum il nous faut un testcase pour pouvoir reproduire le problème.

Thepro (./407) :
Tu es sûr que tes boucles restent après optimisation ?

Effectivement, c'est à vérifier avant de jeter la faute sur TiEmu. (S'il te plaît, mesure exactement le même binaire sur une calculatrice réelle.) Si tu compiles avec GCC 4, tes boucles vides, après optimisation, paf elles sont parties. Il ne faut jamais temporiser avec des boucles vides.

Zephyr (./408) :
le programme en question c'est Einstein ? si oui, pour quelle raison faut-il le temporiser ? (c'est seulement pour le délai de répétition entre deux touches ?)

Oui c'est pour les touches, tout simplement.

Thepro (./407) :

Thibaut (./404) :
Comme il se sert de boucle vides pour se temporiser

Tu es sûr que tes boucles restent après optimisation ?

Oui car j'ai piqué la routine WaitForMillis de la TICT, qui est en assembleur

Kevin Kofler (./410) :
Peut-être. Au minimum il nous faut un testcase pour pouvoir reproduire le problème.

http://alineasofts.free.fr/index.php?rubrique=Einstein
J'ai été obligé de multiplier les temps de pause par 10 pour retrouver à peu près la même vitesse ! TIEmu tourne donc à environ 120 MHz chez moi

le pb vient peut-être de ce que tu n'avais pas déclaré WaitForMillis en stkparm ?

Tu pourrais utiliser WaitForMillis en regparm, non ?

Ca ne vient pas de là, il est bien déclaré avec stkparm

J'ai encore un bug à signaler : TIEmu se ferme violemment quand je clique sur RUN dans le débuger.

Lequel? Celui du Source Window? Le Run de Insight ne veut pas dire grand chose dans le contexte de TiEmu, il faudrait que je vire ça ou que je le fasse faire autre chose (la même chose que Continue, comme pour le Run de la fenêtre Disassembly? Debug file with TiEmu? encore autre chose?).

J'en sais rien. Votre déguger me paraît compliqué à côté de celui de TIEmu, je m'y perds J'ai cliqué sur un bouton avec une boule verte dessinée dessus.

Le débogueur de TiEmu+GDB souffre un peu du fait d'être la fusion de 2 débogueurs en principe indépendants: le débogueur style VTI de TiEmu et le frontend GDB Insight. C'est pour ça que c'est un peu le bordel.

Ce serait pratique, un testcase, effectivement.

C'est quand que ça bloque? À l'envoi déjà? Ou au lancement? Normalement le .dbg n'est pas utilisé du tout à l'envoi, il n'est chargé que quand le program entry breakpoint est atteint, donc si c'est à l'envoi que ça bogue, ce n'est pas un problème d'informations de débogage.