La récente décision d’Apple de reconcevoir ses ordinateurs Mac autour de puces maison, en remplacement d’Intel, a donné un coup de projecteur sur une catégorie de processeurs qu’il y a de fortes chances que vous possédiez déjà. Car oui, Arm est partout.
Le choix d’ARM comme nouvelle plate-forme CPU ne doit rien au hasard, même si, à l’heure actuelle, les alternatives à la famille x86 ne sont guère nombreuses. Apple a adopté ARM pour ses iPhone dès le premier modèle – Apple avait même collaboré avec ARM pour développer le processeur de l’éphémère PDA Newton –, préférant ainsi maîtriser le couple performance-consommation dans un segment de marché où l’autonomie est un facteur critique.
Rapidement, les iPhone sont devenus les cobayes des ingénieurs VLSI. Apple n’a jamais packagé les processeurs ARM dans des boîtiers spécifiques, mais les intègre dans des SoC (System On Chip) qui incorporent également la Flash ROM, la RAM et différents sous-systèmes d’entrée-sortie. Avec la miniaturisation des procédés de gravure et la montée en compétence de l’équipe de conception, chaque nouveau modèle a vu la complexité du SoC augmenter : multi-cœur ARM conçu en interne – Apple ne «licencie» plus que le jeu d’instructions –, puis une avalanche de co-processeurs comme la fameuse «enclave sécurisée», la gestion des capteurs, le GPU et, plus récemment, les processeurs «neuronaux».
Il ne fait aucun doute que Apple équipera ses futurs Mac avec des SoC au moins aussi performants que ceux que l’on trouve actuellement sur les iPhone haut de gamme. Du point de vue de l’utilisateur, on peut ainsi espérer l’apparition sur les MacBook de nouvelles fonctionnalités, des rendus 3D bien plus rapides et des nouveaux logiciels exploitant les bibliothèques d’Intelligence artificielle qui, actuellement, ne fonctionnent qu’avec l’ajout d’un GPU externe.
Maîtrise du compilateur
Mais il y a plus que la maîtrise du processeur. Avec le passage sur ARM, Apple récupère également la maîtrise sur le compilateur, un mouvement amorcé dès 2005/2006. À cette époque, la société californienne envisage d’abandonner GCC, dont le développement est contrôlé par la FSF, Apple ne supervisant que la partie spécifique à MacOS. La transition de GCC vers la licence GPL v3 donne à Apple le prétexte pour passer à l’acte. En réalité, GCC, utilisé pour compiler l’ensemble de MacOS, est un produit soi-disant open source, mais dont la maintenance par des non-initiés est impossible.
Apple va donc se tourner vers un projet naissant de compilateur baptisé LLVM. Elle engage Chris Lattner, son développeur principal. LLVM, et son front-end CLANG, sont non seulement bâtis sur une architecture logicielle moderne, claire et modulaire, mais ils sont également placés sous licence BSD. Double bénéfice pour Apple : la société renforce son image dans l’Open Source en finançant une brique essentielle de tout développement logiciel. LLVM/CLANG sera d’ailleurs ensuite adopté comme compilateur natif par les différents xBSD. Et Apple peut maintenant récupérer tout le code produit par la communauté de développement, y compris hors Apple, pour produire sa propre version, fermée, de LLVM/ CLANG qu’elle fournit avec son environnement de développement Xcode. On peut raisonnablement supposer que le code ARM généré par la version propriétaire diffère de celui généré par la version open source. Les ingénieurs logiciel d’Apple ont dû adapter le back-end à la micro-architecture développée par leurs homologues du hardware. Cette hypothèse a deux conséquences pour le développeur/utilisateur : l’une positive, l’autre négative. La première est évidemment un gain de performance, puisque le code « colle » au plus près des spécifications du hardware. Nul ne sait mieux utiliser un processeur que celui qui le conçoit. On peut donc espérer qu’aux gains purement matériels générés par la transition vers ARM s’ajouteront également des gains logiciels, grâce à une compilation plus efficace. La contrepartie, c’est qu’en prenant le contrôle à la fois du hardware et du compilateur, Apple peut décider de brider n’importe quel aspect de son système d’exploitation sans que personne ne puisse y déroger. Prenons l’exemple du «SIP» (System Integrity Protection) : il s’agit d’un dispositif récent de protection anti-malware mis en place à différents niveaux du système, qui protège notamment les fichiers réputés essentiels contre toute destruction, y compris par l’utilisateur root. Ce dispositif est débrayable, mais uniquement en mode recovery.
Rien n’empêche Apple, dans une future version de ses processeurs, d’implanter le système SIP à l’intérieur même de l’unité d’exécution sous forme d’un registre, d’instructions spécifiques, non documentées, que la version open source de LLVM ne connaîtrait pas, et qui ne seraient pas disponibles dans la version Xcode, voire de développer un co-processeur spécifique. Le résultat serait un système de protection «en dur», impossible à désactiver. Or, on connaît l’obsession de la société californienne vis-à-vis de la sécurité, une obsession qui confine parfois à la paranoïa : comment qualifier autrement le retrait de commandes Unix aussi utiles et répandues que telnet des versions récentes de MacOS ?
Avancées et inquiétudes
Au final, il est indéniable que, pour Apple, maîtriser sa supply chain de bout en bout, du processeur jusqu’à la couche logicielle, est une garantie de minimisation des risques et ouvre la voie à la conception de machines totalement symbiotiques. L’utilisateur devrait y trouver son compte : performances en hausse, plus d’autonomie, plus de fonctionnalités. En outre, la future compatibilité native des applications entre la gamme Mac et les iPad/ iPhone facilitera certainement la tâche des développeurs et devrait favoriser le rapprochement de deux écosystèmes jusqu’ici largement indépendants.
En revanche, cela signifie également que Apple sera libre de placer n’importe quelle entrave et même de la figer dans le marbre du silicium. La relative invulnérabilité du Macintosh aux virus, troyens et autres logiciels malveillants a toujours été mis en avant par la société californienne pour distinguer sa gamme des PC tournant sous Windows. Les récentes évolutions semblent indiquer que les dirigeants d’Apple sont prêts à ériger des murailles pour sauvegarder cette réputation, quitte à tailler dans la souplesse du système Unix sur lequel MacOS est assis. Espérons qu’ils laisseront toujours la possibilité aux utilisateurs de décider comment ils entendent gérer leur machine.
ARM, une techno des années 1980
ARM (Acorn RISC Machine) désigne une gamme de processeurs née dans les années 1980 chez le fabricants d’ordinateurs anglais Acorn pour donner vie à la machine Archimedes. Cette dernière, concurrencée à l’époque par les machines à base de MC 68000 (Apple, Atari, Amiga), puis par le « rouleau compresseur » PC x86, ne survivra que quelques mois. Acorn décide alors de capitaliser sur l’originalité du processeur qu’elle a conçu, où toutes les instructions étaient « câblées » – a contrario des processeurs Intel et Motorola qui exécutaient du microcode – et crée la société ARM autour d’un business model orienté revente de propriété intellectuelle. Depuis cette époque, les ingénieurs d’ARM produisent des schémas d’unités centrales que les clients utilisent sous licence pour réaliser des processeurs, des micro-contrôleurs ou des «SoC» qui combinent le cœur ARM avec différents périphériques ou extensions gravés sur le même silicium. La technologie RISC, qui ne propose que des instructions simples, minimise le nombre de processeurs nécessaires au fonctionnement du CPU, et, partant, sa consommation. C’est la raison pour laquelle les cœurs ARM sont presque toujours adoptés sur les processeurs équipant des systèmes autonomes alimentés sur batteries (smartphones, IoT…).
Source : l'informaticien.com