Nous en avons déjà parlé, l'émulateur Dolphin ne verra a priori pas le jour officiellement sur les appareils d'Apple. La raison principale, c'est qu'Apple interdit aux développeurs d'employer la compilation à la volée pour les applications iOS, pour des raisons de sécurité. Et les développeurs de Dolphin donnent quelques détails.

Pour bien comprendre le problème, un peu de théorie : le principe de base d'un émulateur est de simuler un ordinateur (au sens large) avec un autre ordinateur. Quand les deux appareils n'utilisent pas le même jeu d'instructions, il faut donc convertir les instructions à exécuter du jeu d'instructions de l'appareil à émuler vers celui de l'appareil qui émule. Et si vous ne savez pas ce qu'est un jeu d'instructions, il s'agit simplement de la liste des différentes « commandes » qu'un processeur peut exécuter et elles diffèrent selon le type de CPU.

Dans le cas de Dolphin, c'est assez simple : les consoles émulées — GameCube et Wii — emploient des processeurs PowerPC 32 bits (les mêmes G3 que les anciens Mac) et les appareils iOS des processeurs ARM 64 bits. Un émulateur basique va simplement prendre les instructions une à une, les convertir d'un jeu d'instructions à un autre et les exécuter. Il s'agit d'une technique simple mais lente : pour chaque instruction à exécuter, l'émulateur doit effectuer plusieurs tâches. Dans les faits, c'est une solution efficace si vous avez un ordre de grandeur important entre l'appareil à émuler et celui qui émule. Dans le cas d'une NES, pour rester chez Nintendo, le CPU est une variante de 6502 (un CPU 8 bits) qui tourne à un peu moins de 2 MHz. Pour le GameCube ou la Wii, c'est différent : le PowerPC 750 (G3) est performant et atteint des fréquences de l'ordre de 500 MHz (486 MHz dans le GameCube, 729 MHz dans la Wii), ce qui est finalement assez proche de la puce d'un iPhone (2 à 3 GHz).

La solution de la compilation à la volée (Just-In-Time compilation, employée par Rosetta 2, d'ailleurs) règle en partie le problème : le code est converti à la volée mais mis en cache, pour éviter de recommencer les mêmes tâches encore et encore. Le problème de cette solution, c'est que l'émulateur génère donc du code exécutable qui n'a pas pu être vérifié par Apple, ce qui pose de nombreux soucis de sécurité. Dans la pratique, une seule catégorie d'application peut effectuer de la compilation à la volée : les navigateurs qui exécutent du JavaScript (sans cette solution, le code est très lent).

Ci-JIT l’espoir de voir l’émulateur Dolphin porté sur iPhone

Le cas Dolphin

Les développeurs de Dolphin détaillent un peu les différentes voies possibles… et pourquoi elles sont probablement irréalistes. Premièrement, ils peuvent évidemment tenter de passer entre les mailles du filet en se présentant comme une navigateur ou tentant d'avoir le blanc-seing d'Apple, ce qui est peu probable. Mais ils expliquent que de toute façon, les contraintes imposées dans les navigateurs pour le code en question ne sont pas envisageables pour un émulateur comme Dolphin sans de grosses modifications.

Deuxièmement, ils expliquent que l'idée de certains, qui est de proposer une version qui fonctionne dans un navigateur, est irréaliste même si pas impossible. Le principal problème, c'est que Dolphin n'est pas écrit en JavaScript et vise essentiellement des API graphiques modernes, comme OpenGL, Vulkan ou en partie Metal. Réécrire le code de Dolphin pour qu'il s'exécute en JavaScript et vise une API comme WebGL n'est pas impossible, mais ce n'est pas dans les plans des développeurs. Et c'est surtout un travail de grande ampleur.

Enfin, ils expliquent aussi pourquoi ils ne peuvent pas « précompiler » les applications pour les exécuter nativement. La première raison, qu'ils n'évoquent pas directement, est évidente : effectuer la compilation du code en amont mais sur l'appareil pose exactement le même problème de sécurité. Ils ne peuvent pas effectuer la compilation sur l'iPhone lui-même et l'effectuer en dehors de l'appareil (par exemple sur des serveurs) n'est pas envisageable pour les jeux. En effet, les développeurs ne peuvent évidemment pas distribuer cette version précompilée, étant donné qu'ils ne possèdent pas les droits sur le code.

Émulation légale : ce qu’il faut savoir sur les émulateurs et les ROM

Mais ils expliquent que le problème est plus compliqué : il n'est tout simplement pas toujours possible de convertir le code en amont, parce que les jeux des différentes consoles peuvent s'automodifier. L'exemple donné est simple : certains titres stockent des données compressées sur le disque, qui sont décompressées au lancement. Un programme qui tenterait de convertir le code ne pourrait donc pas effectuer cette tâche. Enfin, certains programmes effectuent de la compilation à la volée sur les consoles, ce qui est évidemment un problème. Typiquement, et ça devient un peu compliqué, Nintendo a distribué des émulateurs de vieilles consoles sur la Wii, qui effectuent de la compilation à la volée pour s'exécuter. Et donc Dolphin peut émuler un émulateur qui émule une Nintendo 64.

C'est un problème qui a par ailleurs posé des problèmes à Apple avec Rosetta 2 : si la compilation à la volée en amont fonctionne assez bien avec de nombreuses applications, elle posait de nombreux soucis avec les navigateurs qui exécutent du JavaScript. En effet, dans ce cas de figure, Apple n'avait pas d'autres choix que d'interpréter le code, bien plus lentement.

Dans tous les cas, vous l'avez compris, si l'arrivée de Dolphin sur l'App Store ou dans un Store alternatif n'est pas totalement impossible, c'est très mal parti. Et les développeurs, rappelons-le, se refusent à distribuer une version sans compilation à la volée, tant les performances sont faibles.