Quand Apple a
introduit la technologie Bitcode et l'a rendue obligatoire pour watchOS et tvOS, la société a semblé ignorer les raisons pour lesquelles elle était nécessaire. Elle a seulement dit vaguement que cela aide à personnaliser les fichiers binaires et utilise les dernières améliorations du compilateur.
Depuis lors, Bitcode a joué un rôle important dans la transition en douceur de watchOS vers 64 bits, où les développeurs n'avaient même pas à recompiler leurs applications dans le répertoire. Apple l'a fait automatiquement: toutes les applications ont commencé à fonctionner sur l'Apple Watch Series 4. Vous n'avez probablement même pas remarqué que la migration s'est produite.
Qu'est-ce que le Bitcode? Eh bien,
bitcode avec petit b est la représentation intermédiaire spécifique à l'architecture utilisée par LLVM, et Bitcode avec grand B fait référence à un ensemble de fonctions qui vous permettent d'incorporer cette vue dans votre binaire Mach-O, et les mécanismes par lesquels vous pouvez rendre ce fichier sur l'App Store.
Le bitcode n'est pas aussi flexible que le code source, mais il est beaucoup plus flexible que le binaire incorporé, avec des métadonnées et des annotations pour le compilateur. En pratique, vous (ou Apple) pouvez facilement extraire les objets blob Bitcode de l'application et les recompiler dans une copie pleinement fonctionnelle de votre application. Passer d'armv7 à armv7s ou d'arm64 à arm64e est très cool et fait gagner du temps aux développeurs qui devaient recompiler le binaire à chaque fois qu'Apple change de puce ARM. Le bitcode est utilisé depuis longtemps par Apple dans les pilotes OpenGL, de sorte que le pilote peut être optimisé à la volée pour diverses architectures GPU.
Nous avons vu comment Microsoft exploite efficacement la recompilation statique sur la Xbox One, donnant accès à toute une bibliothèque de jeux écrits à l'origine pour la Xbox 360 (sous PowerPC), sans la participation des développeurs ni l'accès au code source. Et sans intermédiaire comme Bitcode, ce qui simplifie le processus.
Bien sûr, le fantôme de macOS sur ARM traîne depuis de nombreuses années. Beaucoup se sont demandé si cela faciliterait le portage d'applications à l'aide de Bitcode. En conséquence, ils sont parvenus à un consensus sur le fait que Bitcode ne convient pas pour le transfert entre des architectures radicalement différentes telles qu'Intel et ARM.
Cela ne m'a pas convaincu, j'ai donc décidé de vérifier!
Pour commencer, nous avons besoin d'une application de test simple sur
Objective-C avec Bitcode; il est généralement inclus uniquement lors de la création d'une archive pour l'App Store, vous devez donc le forcer à être inclus dans l'assemblage normal. Vous pouvez utiliser l'
-fembed-bitcode ou l'option de génération personnalisée:
BITCODE_GENERATION_MODE = bitcode
Créez un binaire pour le périphérique iOS générique ou le périphérique connecté, comme d'habitude. Il semble que Bitcode ne soit pas intégré aux assemblages arm64e (par exemple, si vous avez un périphérique A12), vous pouvez donc désactiver le paramètre Xcode «compiler uniquement pour les architectures actives» et compiler directement pour arm64.
En utilisant l'outil
ebcutil, tous les objets
Bitcode sont facilement récupérés à partir d'un binaire compilé.
ebcutil -a arm64 -e path/to/MyApp.app/MyApp
Recompilez ensuite chaque objet Bitcode pour Intel.
for f in *; do clang -arch x86_64 -c -Xclang -disable-llvm-passes -emit-llvm -x ir -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk $f -o $fo; done
Nous allons maintenant relier les blobs compilés au fichier binaire.
clang -arch x86_64 -mios-version-min=12.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk *.o -o path/to/MyApp.app/MyApp
Si cela fonctionne, nous avons maintenant la version x86 de l'application arm64 d'origine! En théorie, il peut être placé directement dans la fenêtre du simulateur iOS, installé et lancé.
C'est un fait très important:
vous pouvez transférer statiquement des fichiers binaires entre les plates-formes Intel et ARM s'ils incluent Bitcode . Ça marche vraiment!
Pièges pour des projets plus complexes
Il semble que l'ARC utilise l'assembleur intégré, donc pour le transfert d'arm64 vers x86 pour le moment, vous devez désactiver ARC.
Certains types de blocs, tels que les gestionnaires de complétion, démarrent le compilateur avec des instructions inacceptables. Si vous obtenez une erreur X87, c'est probablement le problème.
Pourquoi Objective-C? Eh bien, Swift est conçu avec ARC à l'esprit. Je ne pense pas qu'il existe un moyen d'éviter l'assembleur en ligne susmentionné, donc la recompilation échouera maintenant.
Faisons un pas de plus: nous utiliserons
marzipanify pour convertir cette application Intel iOS en un programme Mac qui fonctionne avec Marzipan.
C'était facile!
Théoriquement, cela signifie qu'Apple a un moyen d'exécuter n'importe quelle application iOS depuis l'App Store sur un Mac sans exiger des développeurs qu'ils mettent à jour ou recompilent leurs applications.
Et si le Mac passe d'Intel aux puces ARM? Eh bien, comme vous pouvez le voir, avec Bitcode, il peut transférer toutes les applications compatibles Bitcode vers le Mac App Store sans l'aide des développeurs, il sera donc prêt à changer de processeur dès le premier jour. Cela donne à Apple plus de liberté. Désormais, vous n'avez pas besoin d'annoncer à l'avance la transition vers de nouveaux processeurs un an à l'avance, et une technologie comme Rosetta n'est plus nécessaire.
Évidemment, nous n'avons pas atteint ce point: aujourd'hui, Apple n'inclut pas Bitcode pour les applications dans le Mac App Store, et aujourd'hui Bitcode n'est peut-être pas idéal pour un tel transfert architectural. Au lieu d'Apple, je me concentrerais sur ces deux facteurs et, bien sûr, activer Bitcode pour toutes les applications Marzipan sur macOS 10.15.