Etat de la progression de l'émulateur N64, Daedalus

[Newserator]

StrmnNrmn est plus que jamais déterminé à nous faire savoir qu'il fait de son mieux pour améliorer son émulateur N64, Daedalus. La semaine dernière encore, il essayait d'intégrer un processus de recompilation dynamique dans l'espoir de faire fonctionner son émulateur à une vitesse proche de celle de la console. Aujourd'hui encore, il nous présente des nouveautés.

StrmnNrmn a réussi à assembler différentes portions de code en un code natif x86 pour l'exécuter dynamiquement. Il a opté pour le jeu d'instruction d'Intel plutôt que MIPS afin de rendre le débuggage plus facile.

La conversion de la boucle principale du simulateur en assembleur a été la première étape qu'il a accomplie. Chaque instruction du fragment précédait le code généré suivant:

mise à 1 du PC courant

mise à 1 du "branch delay flag"

obtention de l'opcode dans le registre ECX

appel du gestionnaire de l'opcode spécifié (de R4300.cpp)

si (une exception est levée) alors quitter vers le gestionnaire d'exceptions

si (on rencontre une instruction de branche et que l'on est entré dans la branche) alors quitter vers le gestionnaire de branche

Ce code généré augmentait considérablement la taille du code assembleur (par exemple, 200Ko d'instructions N64 produisait 4Mo de code assembleur x86, ce qui signifiait une augmentation de 2000%), mais cela n'a pas dérangé StrmnNrmn, cas il voulait conserver le comportement initial du fragment autant que possible.

Après quelques heures de débuggage, tout fonctionnait bien, mais le dynarec n'apportait aucune amélioration au niveau des performances, ce qui a poussé StrmnNrmn à optimiser le code généré.

Ce qu'il a fait par la suite a consisté en la suppression du réglage du compteur du programme (l'équivalent du registre EIP pour la N64) avant d'exécuter chaque instruction. Ensuite, étant donné que le flag "branch delay" était toujours mis à 0, il l'a réglé explicitement à 0 ou 1 uniquement si son était devait changer. Il a finalement supprimer toutes les gestion d'exceptions pour les instructions qu'il considérait comme exemptes de risques. Le bloc d'instruction s'est ainsi transformé comme suit:

si (PC nécessaire) alors réglage du PC

si (l'instruction concerne le "branch delay") alors régler le flag sur la bonne valeur

obtention de l'opcode dans le registre ECX

appel du gestionnaire pour l'opcode courant (R4300.cpp)

si (une exception peut être levée et qu'elle l'est) alors quitter vers le gestionnaire d'exception

si (instruction de branche et que l'on y est) alors quitter vers le gestionnaire de branche

Avec cette méthode, 200Ko de code N64 ne donnent plus que 2Mo d'assembleur x86, ce qui réduit le facteur d'expansion à 1000%. La version PC fonctionne désormais 60% plus vite avec le mode dynarec activé.

StrmnNrmn est ensuite passé à la génération du code sur la PSP. Les versions PC et PSP en sont actuellement au même niveau de développement. Le code PSP s'exécute sans plantage, et le mode dynarec apporte un gain de vitesse de l'ordre de 10%.

Cependant, étant donné que StrmnNrmn vient seulement de commencer les optimisations, celles-ci peuvent encore apporter des améliorations impressionnantes. Il nous tiendra informé de la progression de dynarec.

Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=2771

[zeren]

StrmnNrmn est plus que jamais déterminé à nous faire savoir qu'il fait de son mieux pour améliorer son émulateur N64, Daedalus. La semaine dernière encore, il essayait d'intégrer un processus de recompilation dynamique dans l'espoir de faire fonctionner son émulateur à une vitesse proche de celle de la console. Aujourd'hui encore, il nous présente des nouveautés.

StrmnNrmn a réussi à assembler différentes portions de code en un code natif x86 pour l'exécuter dynamiquement. Il a opté pour le jeu d'instruction d'Intel plutôt que MIPS afin de rendre le débuggage plus facile.

La conversion de la boucle principale du simulateur en assembleur a été la première étape qu'il a accomplie. Chaque instruction du fragment précédait le code généré suivant:

mise à 1 du PC courant

mise à 1 du "branch delay flag"

obtention de l'opcode dans le registre ECX

appel du gestionnaire de l'opcode spécifié (de R4300.cpp)

si (une exception est levée) alors quitter vers le gestionnaire d'exceptions

si (on rencontre une instruction de branche et que l'on est entré dans la branche) alors quitter vers le gestionnaire de branche

Ce code généré augmentait considérablement la taille du code assembleur (par exemple, 200Ko d'instructions N64 produisait 4Mo de code assembleur x86, ce qui signifiait une augmentation de 2000%), mais cela n'a pas dérangé StrmnNrmn, cas il voulait conserver le comportement initial du fragment autant que possible.

Après quelques heures de débuggage, tout fonctionnait bien, mais le dynarec n'apportait aucune amélioration au niveau des performances, ce qui a poussé StrmnNrmn à optimiser le code généré.

Ce qu'il a fait par la suite a consisté en la suppression du réglage du compteur du programme (l'équivalent du registre EIP pour la N64) avant d'exécuter chaque instruction. Ensuite, étant donné que le flag "branch delay" était toujours mis à 0, il l'a réglé explicitement à 0 ou 1 uniquement si son était devait changer. Il a finalement supprimer toutes les gestion d'exceptions pour les instructions qu'il considérait comme exemptes de risques. Le bloc d'instruction s'est ainsi transformé comme suit:

si (PC nécessaire) alors réglage du PC

si (l'instruction concerne le "branch delay") alors régler le flag sur la bonne valeur

obtention de l'opcode dans le registre ECX

appel du gestionnaire pour l'opcode courant (R4300.cpp)

si (une exception peut être levée et qu'elle l'est) alors quitter vers le gestionnaire d'exception

si (instruction de branche et que l'on y est) alors quitter vers le gestionnaire de branche

Avec cette méthode, 200Ko de code N64 ne donnent plus que 2Mo d'assembleur x86, ce qui réduit le facteur d'expansion à 1000%. La version PC fonctionne désormais 60% plus vite avec le mode dynarec activé.

StrmnNrmn est ensuite passé à la génération du code sur la PSP. Les versions PC et PSP en sont actuellement au même niveau de développement. Le code PSP s'exécute sans plantage, et le mode dynarec apporte un gain de vitesse de l'ordre de 10%.

Cependant, étant donné que StrmnNrmn vient seulement de commencer les optimisations, celles-ci peuvent encore apporter des améliorations impressionnantes. Il nous tiendra informé de la progression de dynarec.

Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=2771

sa s'annonce plutot prometteur

[Guhux]

J'ai rien compris, mais ca veut dire que ca avance

[rosac]

en gros, le code a été réécrit pour la version pc, et son portage sur psp permettera, dans la prochaine version, d'atteindre un peu + de 10 fps pour un jeu comme mario 64

j'ai juste ??