[ARM] Executer du code natif en gardant le controle - Page 1

Edited_1008

Sa s'appelle de la virtualisation ^^

j'ai pas le temps de faire un long pavé, mais ça peux se faire sur quasiment tous les CPUs du moment qu'il y a une MMU et des modes d'executions type user/provilegié.

Par exemple, http://minivmac.sourceforge.net ou la version d'origine ( http://www.vmac.org ) peux etre compilé pour 68000 et le CPU n'est pas émulé, mais virtualisé.

Ah, l'art de la virtualisation accélérée… C'est un problème assez complexe, et les implémentations efficaces dépendent fortement de la plateforme. Les implémentations génériques (purement logicielles) sont:

• l'interprétation instruction par instruction, comme si on émulait une machine différente, mais la plupart des instructions s'émulent par l'instruction elle-même. Il y a quand-même l'overhead d'aller chercher l'instruction, faire un saut vers la routine qui l'implémente, traduire les modes d'adressage etc., donc c'est très lent.
• l'instrumentation par recompilation dynamique: la même chose, mais en JIT plutôt qu'en interpréteur pur. Cf. par exemple Valgrind. C'est très compliqué et ça reste lent.

Sur certains processeurs, il y a des jeux d'instructions pour la "virtualisation matérielle" qui permettent de faire ça en matériel de manière efficace, c'est le cas notamment des x86 récents. Maintenant, malheureusement, je ne sais pas ce qu'il en est exactement pour ARM, mais j'imagine que ça doit aussi dépendre de quel ARM tu as, sachant qu'il y a beaucoup d'extensions optionnelles au jeu d'instruction de base.

Oui enfin ce sont les deux manieres les moins efficaces qui existent.. (pour faire de la virtualisation.)

Je n'ai pas le temps, j'essayerais de poster un truc la dessus plus tard qui personne n'en parle avant

Godzil (./5) :
Oui enfin ce sont les deux manieres les moins efficaces qui existent.. (pour faire de la virtualisation.)

Je n'ai pas dit le contraire.

Edited_1009

Disons que les methodes "avancé" sont en effet plus simple avec une MMU, sinon il faut faire une forme de JIT et la ça tombe dans du code plutot complexe

Apres il faut voir aussi ce que la MMU peux fournir comme fonctionalitée et ce que le CPU fourni aussi comme fonctionalités.

Le support explicite de la virtualisation est un plus, mais ce que décrit Orion_ est faisable sur n'importe quel CPU qui remplit quelques critères et qui a une MMU.

La méthode classique c'est :
- faire tourner le code de la machine à émuler en mode non privilégié
- utiliser la MMU pour reproduire le mapping (RAM et ROM) de la machine d'origine
- pour les registres hardware, marquer les zone mémoires correspondantes comme non présentes grâce à la MMU
- la majorité du code d'origine tournera "tel quel"
- lorsque qu'une instruction privilégiée ou un accès à un registre hardware sera rencontré, le processeur va générer une exception. À partir de là, on
émule ce qui est nécessaire puis on rend la main au code d'origine.

Les méthodes décrites par Kevin sont plutôt utilisées pour émuler un processeur différent (on peut les utiliser aussi quand c'est le même processeur bien sûr, mais c'est moins efficace que ce qui précède).

Et sans MMU, il n'y a pas moyen de tricher pour y arriver quand même en faisans des relogements à la volée mais "manuellement" avec l'hôte ? (en plombant les perfs, bien entendu !)

C'est compliqué parceque comment savoir si on a un jmp/bra/saut ou des datas?

Enfin ya des astuces aussi dans ce genre la

Pour ta gestion de hardware en parallèle cependant (en imaginant par exemple que tu veux exécuter une GBA sur GP32), usuellement quand on fait un "ému" en JIT on modifie le code d'origine pour appeler régulièrement (par exemple à chaque retour de fonction ou à chaque branchement) une fonction bien de chez nous qui va vérifier s'il faut faire qqch de plus complexe (dessiner une ligne du GPU, générer une sample audio etc.) et brancher ensuite à l'adresse donnée. De toute façon c'est une étape nécessaire si tu n'as pas de MMU ou si le CPU n'est pas 100% binaire-compatible.

Si tu ne fais pas ça par contre, tu tombes en tous cas dans la HLE (émulation haut niveau), et là tu laisses librement exécuter le code d'origine à la vitesse de l'hôte. Tu dois pouvoir définir une interruption qui arrête l'exécution du code invité et dans laquelle tu fais le code de rendu de ta frame. Concrètement ce serait à cheval entre du multiprocess et de l'émulation.
(Par contre évidemment ça c'est pas possible si la fin de frame est supposée arriver à un intervalle bien défini, i.e. que le code invité n'a pas de "WaitForVblank()" -- sans ça, tu dois revenir à la solution précédente.)

Ha non le HLE c'est encore autre chose. Enfin le HLE n'inclue pas forcement que le code soit executé en natif ou interpreté. D'ailleurs non emuler le hardware n'est pas du HLE, le HLE c'est prendre le pas sur des lib "systemes" genre on est obligé d'utiliser des fonctions de la ROM du materiel, on détourne les appels a la ROM par du code natif, ça c'est du HLE.

Par exemple, il y a un émulateur de TI-Z80 pour TI-68k qui utilise une combinaison de recompilation dynamique et de HLE de ROM_CALLs.

Il n'y a pas de 'TRACE' possible comme sur un 68000 ?

Je ne sais pas, mais même s'il y en a un les perfs seraient désastreuses pour un émulateur ^^