{"id":72291,"date":"2012-02-01T09:00:01","date_gmt":"2012-02-01T08:00:01","guid":{"rendered":"https:\/\/cms.galaxiemedia.fr\/tomshardware\/2012\/02\/01\/lemulation-comment-pourquoi\/"},"modified":"2023-06-23T11:53:20","modified_gmt":"2023-06-23T09:53:20","slug":"lemulation-comment-pourquoi","status":"publish","type":"post","link":"https:\/\/www.tomshardware.fr\/lemulation-comment-pourquoi\/","title":{"rendered":"L’\u00e9mulation : comment, pourquoi ?"},"content":{"rendered":"
<\/a><\/span><\/span>Le concept d\u2019\u00e9mulation<\/strong> peut se r\u00e9sumer de fa\u00e7on relativement simple : il s\u2019agit, comme l\u2019explique si bien Wikipedia, de \u00ab substituer un \u00e9l\u00e9ment de mat\u00e9riel informatique \u2013 tel un terminal informatique, un ordinateur ou une console de jeux \u2013 par un logiciel<\/em> \u00bb. Contrairement \u00e0 ce qu\u2019on pourrait supposer, l\u2019\u00e9mulation ne date pas d\u2019hier. Les premiers travaux visant \u00e0 reproduire le comportement d\u2019un mat\u00e9riel informatique donn\u00e9 par un logiciel (ou un couple logiciel\/mat\u00e9riel) remontent en r\u00e9alit\u00e9 aux ann\u00e9es 60. \u00c0 cette \u00e9poque, chaque ordinateur n\u2019est compatible qu\u2019avec lui-m\u00eame, et chaque changement de configuration ou d\u2019architecture demande donc une nouvelle phase de programmation.<\/p>\n\n\n\n\n\n <\/p>\n\n <\/p>\n\n <\/a><\/span><\/span>En 1962, un utilisateur parvient, \u00e0 la grande surprise d\u2019IBM, \u00e0 modifier son IBM 705<\/strong> pour le rendre compatible avec d\u2019anciens programmes \u00e9crits pour IBM 1401<\/a><\/strong>. Le g\u00e9ant se rend alors compte de l\u2019int\u00e9r\u00eat d\u2019assurer une certaine compatibilit\u00e9 entre ses nouveaux mod\u00e8les d\u2019ordinateurs et des mod\u00e8les plus anciens. C\u2019est le d\u00e9but du concept de compatibilit\u00e9 descendante<\/strong>. IBM confie \u00e0 son laboratoire fran\u00e7ais de La Gaude la mission de mettre au point une solution logicielle<\/strong> imitant le comportement de ses 7 ordinateurs les plus populaires. Le r\u00e9sultat est h\u00e9las d\u00e9cevant, le \u00ab simulateur<\/strong> \u00bb n\u2019atteignant au mieux que la moiti\u00e9 des performances des machines originales. Dans le pire des cas, il \u00e9tait dix fois moins rapide\u2026 <\/a><\/span><\/span><\/p>\n\n\n\n\n\n <\/p>\n\n L\u2019\u00e9mulation repose sur une id\u00e9e relativement simple : traduire le jeu d\u2019instruction<\/strong> d\u2019une architecture source vers celui d\u2019une architecture destination. C\u2019est ce qu\u2019on appelle la traduction de code<\/strong>, ou binary translation. Il n\u2019est pas n\u00e9cessaire que les deux jeux d\u2019instruction soient diff\u00e9rents : on peut en effet d\u00e9cider d’\u00e9muler une architecture donn\u00e9e sur une m\u00eame architecture \u00e0 des fins de test ou de d\u00e9bogage<\/strong>.<\/p>\n\n\n\n\n\n <\/p>\n\n <\/p>\n\n Deux types de traduction de code existent : la traduction statique<\/strong>, o\u00f9 le fichier ex\u00e9cutable est alors traduit de la machine source vers un ex\u00e9cutable interpr\u00e9table par la machine de destination, et la traduction dynamique<\/strong>. Dans ce dernier cas, l\u2019\u00e9mulateur se charge de traduire \u00e0 la vol\u00e9e<\/strong> les instructions de la machine source vers des instructions de la machine cible, au moment m\u00eame de leur ex\u00e9cution.<\/p>\n\n\n\n\n\n <\/p>\n\n L\u2019\u00e9mulateur est \u00e9galement charg\u00e9 d\u2019imiter le contenu des p\u00e9riph\u00e9riques de stockage (en utilisant soit des fichiers images, soit des p\u00e9riph\u00e9riques physiques), mais \u00e9galement les entr\u00e9es\/sorties, la carte r\u00e9seau, la carte son et bien entendu le processeur (CPU, FPU, MMU, …).<\/p>\n <\/a><\/span><\/span>L’un des exemples les plus r\u00e9cents de l’utilisation d’un \u00e9mulateur pour permettre de r\u00e9utiliser des \u00ab anciennes \u00bb applications sur un nouveau parc d’ordinateurs est probablement Rosetta<\/strong>. En 2006, Apple a commenc\u00e9 \u00e0 commercialiser de nouveaux mod\u00e8les d\u2019ordinateurs \u00e9quip\u00e9s d\u2019un processeur Intel x86, \u00e0 la place des PowerPC jusqu\u2019alors utilis\u00e9s. Les architectures <\/strong>x86 et PPC \u00e9tant de conception fondamentalement diff\u00e9rente, il a fallu qu\u2019Apple int\u00e8gre au syst\u00e8me d\u2019exploitation une solution permettant d\u2019ex\u00e9cuter, sans modification pr\u00e9alable, des logiciels con\u00e7us et compil\u00e9s pour Mac OS X \u00ab PowerPC<\/strong> \u00bb sur les ordinateurs \u00e0 base de processeurs Intel<\/strong>.\u00a0<\/p>\n\n <\/p>\n\n Apple avait d\u2019ailleurs d\u00e9j\u00e0 rencontr\u00e9 ce probl\u00e8me lors de la transition entre les Macintosh 68k<\/strong> et les Power Macintosh<\/strong>, \u00e0 base de processeurs PowerPC. \u00c0 l\u2019\u00e9poque, le constructeur avait int\u00e9gr\u00e9 un \u00e9mulateur de processeurs Motorola 680×0<\/a>, Mac 68k<\/strong>, dans toutes les versions PowerPC de Mac OS. Il devenait d\u00e8s lors possible d\u2019\u00e9xecuter sur un Power Mac des applications \u00e9crites pour un Macintosh 68k.<\/p>\n\n <\/p>\n\n <\/p>\n\n C\u2019est donc en toute logique que Rosetta a fait son apparition dans Mac OS X 10.4.4<\/strong>. Gr\u00e2ce \u00e0 cet \u00e9mulateur, il fut possible d\u2019utiliser les applications PowerPC sur les Macs \u00e9quip\u00e9s d\u2019un processeur Intel, et ce de mani\u00e8re transparente pour l\u2019utilisateur. Cet \u00e9mulateur a \u00e9galement \u00e9t\u00e9 disponible avec les versions suivantes de Mac OS X, mais \u00e0 partir de Snow Leopard (Mac OS X 10.6) l\u2019installation de Rosetta devint optionnelle. Enfin, Apple retira Rosetta de Lion<\/a> (Mac OS X 10.7), ce qui signa la fin de la compatibilit\u00e9 de Mac OS X avec les applications PowerPC.<\/p>\n\n <\/p>\n\n
Mais pourquoi avons-nous besoin d\u2019\u00e9muler du mat\u00e9riel informatique ? S\u2019agit-il de faciliter le d\u00e9veloppement<\/strong> ou le d\u00e9bogage<\/strong> d\u2019un syst\u00e8me ? D\u2019utiliser d\u2019anciens programmes cr\u00e9\u00e9s pour un syst\u00e8me obsol\u00e8te ou inutilisable<\/strong> ? Ou bien de faire revivre de vieilles consoles de jeu (ou des bornes d\u2019arcade) ? Peut-\u00eatre un peu de tout cela. Une chose est s\u00fbre : l’\u00e9mulation existe depuis de tr\u00e8s nombreuses ann\u00e9es et nous ne sommes pas encore pr\u00eats \u00e0 nous en passer.<\/p>\nHistoire de l’\u00e9mulation<\/h2>\n
De la simulation \u00e0 l’\u00e9mulation<\/h4>\n\n\n\n\n\n
Pour obtenir des performances<\/strong> acceptables, il fallait donc m\u00e9langer deux id\u00e9es : une architecture mat\u00e9rielle<\/strong> aussi proche que possible de la machine \u00e0 simuler, et un programme de simulation<\/strong>. IBM confia donc \u00e0 une autre \u00e9quipe, dirig\u00e9e par l\u2019ing\u00e9nieur Stuart Tucker, la t\u00e2che de d\u00e9velopper une solution efficace capable d\u2019ex\u00e9cuter des programmes con\u00e7us pour IBM 7070<\/strong> \u2013 le plus sophistiqu\u00e9 des ordinateurs IBM de l\u2019\u00e9poque \u2013 sur un ordinateur NPL (\u00ab New Product Line \u00bb)\u00a0 alors en d\u00e9veloppement. L\u2019un des membres de l’\u00e9quipe, Larry Moss, parvient \u00e0 mettre au point une solution n\u2019affichant aucune perte de performance. Le premier \u00ab \u00e9mulateur<\/strong> \u00bb \u00e9tait n\u00e9.
Le 7 avril 1964, IBM lance ses System\/360<\/strong> en y int\u00e9grant l\u2019\u00e9mulateur de Moss, plus connu sous le n<\/a><\/span><\/span>om de 7070 Emulator<\/strong>. D\u2019autres versions du System\/360<\/a>, capables d\u2019\u00e9muler d\u2019autres mod\u00e8les d\u2019ordinateurs IBM, virent \u00e9galement le jour (360-30 capable d\u2019\u00e9muler les IBM 1400 Series, ou 360-65 \u00e9mulant l\u2019IBM 7094). Les System\/360 furent commercialis\u00e9s jusqu\u2019en 1978, les utilisateurs appr\u00e9ciant tout particuli\u00e8rement de pouvoir r\u00e9utiliser leurs anciens programmes.
Les \u00e9mulateurs n\u2019ont cess\u00e9 d\u2019\u00e9voluer, mais l\u2019objectif est toujours rest\u00e9 le m\u00eame : reproduire le comportement<\/strong> d\u2019un mod\u00e8le d\u2019ordinateur ou d\u2019une architecture donn\u00e9e, \u00e0 partir d\u2019un autre mod\u00e8le ou d’une autre architecture. Avec la mont\u00e9e en puissance des ordinateurs r\u00e9cents, une \u00e9mulation mat\u00e9rielle est de moins en moins indispensable pour obtenir une vitesse d\u2019ex\u00e9cution acceptable, ce qui explique le succ\u00e8s des \u00e9mulateurs logiciels, en particulier depuis la fin des ann\u00e9es 1990.<\/p>\nEmuler une architecture : la traduction binaire dynamique<\/h2>\n
Traduction statique ou dynamique<\/h4>\n\n\n\n\n\n
Rosetta : la couche d\u2019\u00e9mulation de Mac OS X<\/h2>\n
Un \u00e9mulateur PowerPC dans Mac OS X<\/h4>\n\n