Introduction
Le concept d’émulation peut se résumer de façon relativement simple : il s’agit, comme l’explique si bien Wikipedia, de « substituer un élément de matériel informatique – tel un terminal informatique, un ordinateur ou une console de jeux – par un logiciel ».
Mais pourquoi avons-nous besoin d’émuler du matériel informatique ? S’agit-il de faciliter le développement ou le débogage d’un système ? D’utiliser d’anciens programmes créés pour un système obsolète ou inutilisable ? Ou bien de faire revivre de vieilles consoles de jeu (ou des bornes d’arcade) ? Peut-être un peu de tout cela. Une chose est sûre : l’émulation existe depuis de très nombreuses années et nous ne sommes pas encore prêts à nous en passer.
Histoire de l’émulation
Contrairement à ce qu’on pourrait supposer, l’émulation ne date pas d’hier. Les premiers travaux visant à reproduire le comportement d’un matériel informatique donné par un logiciel (ou un couple logiciel/matériel) remontent en réalité aux années 60. À cette époque, chaque ordinateur n’est compatible qu’avec lui-même, et chaque changement de configuration ou d’architecture demande donc une nouvelle phase de programmation.
De la simulation à l’émulation
En 1962, un utilisateur parvient, à la grande surprise d’IBM, à modifier son IBM 705 pour le rendre compatible avec d’anciens programmes écrits pour IBM 1401. Le géant se rend alors compte de l’intérêt d’assurer une certaine compatibilité entre ses nouveaux modèles d’ordinateurs et des modèles plus anciens. C’est le début du concept de compatibilité descendante. IBM confie à son laboratoire français de La Gaude la mission de mettre au point une solution logicielle imitant le comportement de ses 7 ordinateurs les plus populaires. Le résultat est hélas décevant, le « simulateur » n’atteignant au mieux que la moitié des performances des machines originales. Dans le pire des cas, il était dix fois moins rapide…
Pour obtenir des performances acceptables, il fallait donc mélanger deux idées : une architecture matérielle aussi proche que possible de la machine à simuler, et un programme de simulation. IBM confia donc à une autre équipe, dirigée par l’ingénieur Stuart Tucker, la tâche de développer une solution efficace capable d’exécuter des programmes conçus pour IBM 7070 – le plus sophistiqué des ordinateurs IBM de l’époque – sur un ordinateur NPL (« New Product Line ») alors en développement. L’un des membres de l’équipe, Larry Moss, parvient à mettre au point une solution n’affichant aucune perte de performance. Le premier « émulateur » était né.
Le 7 avril 1964, IBM lance ses System/360 en y intégrant l’émulateur de Moss, plus connu sous le n
om de 7070 Emulator. D’autres versions du System/360, capables d’émuler d’autres modèles d’ordinateurs IBM, virent également le jour (360-30 capable d’émuler les IBM 1400 Series, ou 360-65 émulant l’IBM 7094). Les System/360 furent commercialisés jusqu’en 1978, les utilisateurs appréciant tout particulièrement de pouvoir réutiliser leurs anciens programmes.
Les émulateurs n’ont cessé d’évoluer, mais l’objectif est toujours resté le même : reproduire le comportement d’un modèle d’ordinateur ou d’une architecture donnée, à partir d’un autre modèle ou d’une autre architecture. Avec la montée en puissance des ordinateurs récents, une émulation matérielle est de moins en moins indispensable pour obtenir une vitesse d’exécution acceptable, ce qui explique le succès des émulateurs logiciels, en particulier depuis la fin des années 1990.
Emuler une architecture : la traduction binaire dynamique
L’émulation repose sur une idée relativement simple : traduire le jeu d’instruction d’une architecture source vers celui d’une architecture destination. C’est ce qu’on appelle la traduction de code, ou binary translation. Il n’est pas nécessaire que les deux jeux d’instruction soient différents : on peut en effet décider d’émuler une architecture donnée sur une même architecture à des fins de test ou de débogage.
Traduction statique ou dynamique
Deux types de traduction de code existent : la traduction statique, où le fichier exécutable est alors traduit de la machine source vers un exécutable interprétable par la machine de destination, et la traduction dynamique. Dans ce dernier cas, l’émulateur se charge de traduire à la volée les instructions de la machine source vers des instructions de la machine cible, au moment même de leur exécution.
L’émulateur est également chargé d’imiter le contenu des périphériques de stockage (en utilisant soit des fichiers images, soit des périphériques physiques), mais également les entrées/sorties, la carte réseau, la carte son et bien entendu le processeur (CPU, FPU, MMU, …).
Rosetta : la couche d’émulation de Mac OS X
L’un des exemples les plus récents de l’utilisation d’un émulateur pour permettre de réutiliser des « anciennes » applications sur un nouveau parc d’ordinateurs est probablement Rosetta. En 2006, Apple a commencé à commercialiser de nouveaux modèles d’ordinateurs équipés d’un processeur Intel x86, à la place des PowerPC jusqu’alors utilisés. Les architectures x86 et PPC étant de conception fondamentalement différente, il a fallu qu’Apple intègre au système d’exploitation une solution permettant d’exécuter, sans modification préalable, des logiciels conçus et compilés pour Mac OS X « PowerPC » sur les ordinateurs à base de processeurs Intel.
Apple avait d’ailleurs déjà rencontré ce problème lors de la transition entre les Macintosh 68k et les Power Macintosh, à base de processeurs PowerPC. À l’époque, le constructeur avait intégré un émulateur de processeurs Motorola 680×0, Mac 68k, dans toutes les versions PowerPC de Mac OS. Il devenait dès lors possible d’éxecuter sur un Power Mac des applications écrites pour un Macintosh 68k.
Un émulateur PowerPC dans Mac OS X
C’est donc en toute logique que Rosetta a fait son apparition dans Mac OS X 10.4.4. Grâce à cet émulateur, il fut possible d’utiliser les applications PowerPC sur les Macs équipés d’un processeur Intel, et ce de manière transparente pour l’utilisateur. Cet émulateur a également été disponible avec les versions suivantes de Mac OS X, mais à partir de Snow Leopard (Mac OS X 10.6) l’installation de Rosetta devint optionnelle. Enfin, Apple retira Rosetta de Lion (Mac OS X 10.7), ce qui signa la fin de la compatibilité de Mac OS X avec les applications PowerPC.
Rosetta est capable de traduire les instructions des PowerPC G3 et G4, ainsi que le jeu d’instructions AltiVec. L’émulateur ne prend en revanche pas en charge les instructions propres au PowerPC G5 (PowerPC 970, 970FX et 970MP). L’émulation via Rosetta reste toutefois lourde, la traduction du code à la volée demandant beaucoup de ressources CPU, ce qui explique d’ailleurs que de nombreuses applications PowerPC s’exécutent certes sur un Mac Intel, mais de façon plutôt lente. Il faut donc voir Rosetta comme une solution temporaire pour Apple, le temps que les développeurs basculent du PowerPC vers le x86. Mais l’objectif pour Apple était atteint : faire cohabiter pendant une période de transition un parc de machines PowerPC avec de nouveaux Macs utilisant un processeur Intel.
Les consoles qui émulent d’autres consoles
L’émulation est également très présente sur le marché ludique. Ainsi, de nombreuses consoles de jeu aujourd’hui disparues du marché continuent d’exister sur nos ordinateurs (ou sur d’autres consoles de jeu) grâce à des émulateurs. Dans le cas des consoles de jeu, il s’agit également souvent d’assurer une certaine rétrocompatibilité avec les jeux destinés à une console plus ancienne.
Le cas de la PlayStation 3
L’un des exemples les plus connus – et les plus récents – est peut-être la rétrocompatibilité de la PlayStation 3 de Sony avec les précédentes PlayStation. En 2006, deux versions de la PlayStation 3 sont lancées : une première équipée d’un disque dur de 60 Go, rétro-compatible avec les PlayStation 1 et 2, et une seconde dotée d’un disque dur de 20 Go et uniquement compatible avec les jeux PS1. Pour assurer cette compatibilité, en particulier avec la PS2, Sony a fait le choix d’intégrer des composants de la PlayStation 2 – à savoir les Emotion Engine et Graphic Synthetizer – dans sa nouvelle console. Il s’agissait donc d’émulation quasi-matérielle, seule la partie audio étant réellement émulée.
La version européenne n’intégrait toutefois pas l’Emotion Engine (pour des raisons de coûts), qui était alors émulé de manière logicielle. En contrepartie, seuls 75% des jeux PS2 étaient compatibles. Les versions ultérieures de la PlayStation ont purement et simplement abandonné la rétrocompatibilité avec la PS2.
Les consoles de Nintendo et Microsoft
En utilisant des composants relativement proches dans ses différentes consoles de jeu, Nintendo est quant à lui capable d’assurer une certaine compatibilité entre certaines de ses consoles sans avoir besoin d’une couche complexe d’émulation. La Wii est ainsi compatible avec les jeux de la GameCube, les composants des deux consoles étant similaires (processeur Broadway, variante du Gekko de la GameCube basé sur le PowerPC d’IBM).
Microsoft a également pu rendre sa console Xbox 360 (basée sur une architecture PowerPC et dotée d’un GPU ATI Xenos) rétro compatible avec les jeux pour Xbox (console basée sur une architecture x86 et embarquant un chipset graphique NVIDIA NV2a), grâce à un émulateur. Cette fonctionnalité demande toutefois la présence d’un disque dur, les jeux d’origine devant être patchés pour fonctionner convenablement.
Les émulateurs de PC, consoles et smartphones
De très nombreux émulateurs, plus ou moins complets et fonctionnels, existent et peuvent être téléchargés (gratuitement pour la plupart). Il aurait été difficile d’en faire une liste complète, mais quelques-uns sortent tout de même du lot.
Les émulateurs de systèmes x86, 68k ou PowerPC
Du côté des émulateurs d’ordinateurs, on citera par exemple Basilik II (un émulateur Open Source 68k Macintosh), Pear PC (un émulateur du processeur PowerPC destiné aux processeurs x86), Bochs (un émulateur de machine x86) ou encore le célèbre QEMU (émulateur de système x86, PPC, ARM, MIPS, SPARC,…). C’est d’ailleurs ce dernier qui sert de base à l’émulateur intégré au SDK Android de Google.
Certains émulateurs sont de véritables petits bijoux de programmation, comme cet émulateur de système x86 programmé en JavaScript et capable de faire tourner Linux.
Du côté des joueurs
Les joueurs retiendront quant à eux DOSBox (un émulateur 286/386 permettant de faire tourner de “vieux” jeux DOS), MAME (Multiple Arcade Machine Emulator, un émulateur de bornes d’arcade) et MESS (un émulateur de consoles de jeu basé sur MAME).
Ces deux derniers émulateurs émulent le plus fidèlement possible chaque composant. MAME et MESS adoptent par ailleurs une vue puriste de l’émulation, interdisant des modifications pouvant faire fonctionner un jeu correctement ou plus rapidement. En contrepartie, l’émulation de ces jeux demande beaucoup de puissance CPU.
Conclusion
Nous l’avons vu, l’émulation peut avoir plusieurs objectifs. Elle peut faciliter le développement et/ou le débogage d’un programme destiné à une architecture. Elle peut également permettre de continuer à utiliser de vieux programmes, conçus pour d’anciens systèmes, sur un système plus récent mais nativement incompatible. L’émulation peut enfin servir à lancer des programmes où des jeux conçus pour une architecture matérielle totalement différente de celle du système hôte.
Le principal inconvénient de l’émulation reste son besoin en ressources CPU. Pour émuler convenablement un système donné, le système hôte doit être beaucoup plus puissant. A défaut, le programme risque de s’exécuter beaucoup plus lentement que prévu. Il est possible d’accélérer matériellement l’ensemble, mais l’émulation assistée matériellement a bien entendu un coût plus important qu’une émulation exclusivement logicielle. L’émulation est donc un équilibre entre vitesse d’exécution, qu’il est possible d’améliorer en utilisant un processeur plus puissant ou bien en optimisant le fonctionnement de l’émulateur, et investissement financier : un processeur plus puissant sera également plus cher, et l’ajout de composants supplémentaires pour assurer une accélération matérielle aura un coût. Une chose est sûre : l’émulation est un domaine en constante évolution.
