Fin 2019, Apple devrait sûrement sonner le glas des instructions x86 32 bits dans ses OS (et ne garder que le 64 bits). Mais saviez-vous qu’avec les premiers PowerPC, la marque avait déjà dû gérer des problèmes de jeux d’instructions ? Et dès la première génération de PowerPC ?
Revenons en arrière. Avec la première génération de Power Macintosh, en 1994, Apple utilise le premier processeur PowerPC du marché, le PowerPC 601. Cette puce était dérivée du POWER1, un CPU haut de gamme de chez IBM, destiné plutôt aux serveurs (comme le PowerPC 970, alias G5, dérive du POWER4). Et ce statut un peu hybride impliquait une chose : il supportait le jeu d’instructions des PowerPC mais aussi quelques instructions issue de l’architecture POWER (largement similaire, par ailleurs). Et certains compilateurs de l’époque permettaient de générer du code qui mélangeait des instructions PowerPC et des instructions POWER.
Avec la seconde génération de PowerPC chez Apple (notamment les 603 et les 604), les processeurs n’intègrent que le jeu d’instructions PowerPC (et pas les instructions POWER, donc). Du coup, un problème se posait : les programmes compilés spécifiquement pour le PowerPC 601 pouvaient ne pas fonctionner. Apple avait donc dû développer un émulateur interne capable d’interpréter les instructions POWER en question (PowerPC 601 compatibility), bien évidemment avec une pénalité sur les performances. Apple recommandait donc aux développeurs de générer du code « POWER-clean », c’est-à-dire compilé sans les instructions POWER. Les développeurs qui proposaient des programmes PowerPC devaient donc souvent recompiler leurs logiciels pour qu’ils tournent correctement sur les nouveaux PowerPC.
En 2019, j’ai surtout trouvé des références au code POWER-clean dans les Developer Note d’Apple. Je n’ai pas trouvé d’informations sur des logiciels touchés par le problème, mais si vous avez un exemple dans une archive, ça m’intéresse, juste pour voir le problème. Mais en tout cas l’anecdote montre que même il y a plus de 25 ans, Apple devait jouer avec les problèmes de compatibilité dans les processeurs… A noter, enfin, que les processeurs PowerPC et POWER finiront par uniformiser avec le temps les jeux d’instructions et que les POWER actuels (comme le POWER9) utilisent un jeu d’instructions PowerPC, mais dans une version forcément plus récente que les derniers Mac PowerPC (qui ont bientôt 15 ans).
Le PowerPC fut quand même extrèmement bien conçu au niveau jeu d’instruction.
Quand on voit le bazar chez Intel, ARM qui a du refaire un jeu complet avec le 64bits (au point, actuellement, de traîner désormais, pour la compatibilité des binaires, 3 jeux d’instructions: 64, 32, Thumb en taille d’instruction variable pour économiser la mémoire des petits systèmes ; voir un quatrième avec Jazelle, mais qui devient rare vu qu’il a été un échec car Google n’a pas voulu se lier pieds et poings à ARM pour accélérer Java sous Androïd, pas fous!)…
Il y a eu des extensions, mais la base du jeu d’instruction n’a quasiment pas évolué en 20 ans à en manger (avec bonheur, tant cette architecture est séduisante) dans l’industrie télécoms (qui passe avec fleurs et couronnes à venir chez Intel, sauf Huawei qui évite cette sombre connerie… et après ça on vous rabats les oreilles avec la sécu alors qu’Ericsson et Nokia font une 5G NSA-Inside via le ME de leurs Xeons et Atoms de merde). Même le passage 64 bits n’a presque rien changé.
Apple a planté les premiers clous du cercueil PPC… L’industrie télécoms les derniers. Et c’est ceux qui font de l’auto-motive/avionique (bénéficiant jusque là du débug composant de l’indus télécoms adaptés au critique) qui vont très vite se retrouver dans la merde: Intel impossible (ME, inutile complexité à tous les étages résultant du crédo de la compatibilité binaire, manque total de déterminisme) et ARM aussi (une tétra-chiée d’états indéfinis = incertifiable pour du critique).