---

Code Binaire Universel

Actuellement, nous vivons une nième transition d'Apple qui abandonne l'architecture PowerPC pour aller vers le matériel équipé Intel. Une transition équivalente doit s'opérer au niveau logiciel. De fait, les utilisateurs de l'IDE FutureBASIC pourraient se demander tout ce que cela signifie pour leurs applications déjà existantes ou bien celles, dans leurs cartons, qui sont encore à venir. Bien qu'aucune spéculation ne puisse être encore faite en ce qui concerne les futures versions de l'IDE FutureBASIC, on peut déjà présenter des considérations générales sur ce qui doit être réalisé par les concepteurs de FB, et à leur suite, par tous les programmeurs FB.

En juin 2005, Apple a annoncé que la transition en question devait s'achever en 2007, mais elle s'est terminée dans les faits à la fin 2006. Pour amortir le choc de cette introduction prématurée, Apple a dépensé une grande énergie à motiver les développeurs de logiciels en leur offrant de quoi créer rapidement des applications capables de s'exécuter nativement sur des Mac Intel. La source essentielle d'informations pour toutes les questions relatives à cette transition se trouve à “Developer Transition Resource Center”. Apple prévoie également des sessions dédiées lors de sa WWDC (conférence annuelle pour les développeurs du monde entier) qui se tiendra à San Francisco en août 2006. De plus, pour la toute première fois, Apple a organisé au niveau mondial des stages gratuits pour les membres de l'ADC (réseau de développeurs Apple) portant sur les applications en code binaire universel au cours desquels des spécialistes du Mac fournissent une aide technique détaillée aux développeurs et leur laissent tester leurs applications sur le tout nouveau matériel.

La plupart des faits relatés dans ce bref rapport peuvent être retrouvés dans le document d'Apple “Universal Binary Programming Guidelines, Second Edition” (8 mars 2006) qui est aussi disponible en téléchargement au format PDF. D'autres informations proviennent de l'édition allemande du magazine Macworld et des services de MacNN. Remarques et opinions figurent entre crochets.

À partir de maintenant, toutes les applications Mac devront être soi-disant en "Code Binaire Universel"

Une application en "Code Binaire Universel" est un paquet logiciel similaire aux applications empaquetées de Mac OS X, mais qui contient un fichier de code binaire compilé pour Intel et un autre pour PPC. Comme d'habitude, le paquet contient des ressources, des fichiers d'aide et d'autres choses encore qui sont tous exploitables par les deux versions du code. Ce partage des ressources diminue la taille des applications.
[ En réalité, les applications peuvent contenir beaucoup plus de fichiers de code binaire qui pourront supporter, par exemple, la prochaine architecture Intel 64 bits — pour des applications spéciales sans interface utilisateur — ou encore PPC 64 bits.]

Apple décourage fortement la compilation ciblant la plate-forme Intel exclusivement.
[ Bien que cette recommandation soit principalement faite pour ne pas dérouter l'utilisateur qui souhaiterait transférer ses logiciels d'un Mac Intel vers un Mac PPC, il est possible qu'elle résulte du souhait d'Apple de garder la main-mise sur le processeur équipant ses machines. Rappelez-vous que le facteur essentiel présidant à la transition vers Intel a été l'absence de processeur PPC adéquat pour sa gamme de portables.]

La technique sous-jascente aux fichiers de code binaire universel remonte à la première moitié des années 90 lorsque NeXT a développé ce qui s'est appelé par la suite les "applications FAT" qui pouvaient s'exécuter sur quatre plates-formes différentes.

Sur Mac, tous les fichiers de code binaire universel doivent être au format “Mach-O” exécutable.
[ Présentement, FB utilise toujours le format CFM/PEF et il ne compile que pour le PPC, si l'on exclut l'historique 68K.]

À ce jour, il y a seulement trois compilateurs qui génèrent du code “Mach-O” pour les Mac Intel : le compilateur gcc4 qui fait partie de Xcode 2.2 et les tout nouveaux compilateurs C(++)/FORTRAN d'Intel.
[ En passant, il se dit que le code d'Intel est (légèrement) meilleur que celui produit par ggc4 bien qu'Apple ait suggéré et implémenté de nombreuses améliorations du compilateur gcc. — Xcode 2.3 sera très bientôt disponible.]

Le code PPC universel peut être compilé pour Mac OS X 10.4.x, 10.3.9 [ ou peut-être même 10.2.8 ] — en fonction du SDK utilisé — mais pas pour les versions antérieures de Mac OS X.

Xcode 2.2 est livré avec un utilitaire appelé “lipo” [ encore un héritage de NEXTStep ] qui produit des applications en code binaire universel à partir de différents fichiers de code au format “Mach-O”. Cela signifie que l'on peut obtenir du code binaire universel quel que soit le compilateur utilisé pour produire le code au format Mach-O pour PPC et Intel.
[ Actuellement, les seules alternatives à gcc4 sont les compilateurs Intel ci-avant mentionnés, mais on attend la très prochaine sortie d'un autre compilateur FORTRAN réalisé par Absoft.]

Les processeurs Intel n'ont pas d'unité Altivec [ unité plus connue sous le nom de Velocity Engine sur Mac ]. Leur unité de traitement vectoriel est appelée SSE2 et elle fonctionne différemment de l'Altivec de Motorola. Lorsqu'on utilise le Framework accéléré d'Apple, Xcode produit le code vectoriel approprié à la cible de la compilation, Intel ou PPC.

Les applications en code binaire universel doivent être testées sur PPC et sur Mac Intel. C'est-à-dire qu'il vous faudra disposer des deux types de machines !

Les applications en code binaire universel ne fonctionnent pas avec des plug-ins exclusivement PPC — mais voyez plus bas.

Que se passe-t-il avec les applications exclusivement PPC sur des Mac Intel ?

Les Mac Intel exécutent les applications PPC à l'aide d'un interpréteur logiciel appelé "Rosetta" qui traduit dynamiquement le code exécutable. Rosetta n'est pas un environnement d'exécution séparé comme l'est "Classic", et l'utilisateur n'est en principe pas informé du type d'application — code binaire universel ou bien PPC — qui est en train d'opérer, peut-être notera-t-il une exécution plus lente due au travail de “Rosetta”, bien que ce ralentissement soit négligeable pour des éditeurs de texte et autres applications de ce genre.

"Rosetta" est compatible CFM/PEF et Mach-O et supporte le code Altivec. Il n'exécute pas les applications prédatant Mac OS X, ni l'environnement Classic, ni les applications nécessitant un processeur G5, ou encore certaines variétés de code un peu spéciales que FB ne produit pas de toute façon. Le plus important : Il n'y a aucun moyen de faire tourner des applications écrites pour des systèmes antérieurs à Mac OS X sur des Mac Intel.
[ Mac OS X 10.4.x supporte toujours l'environnement Classic sur les Mac PPC, mais le logiciel système est livré maintenant amputé de MacOS 9.2.x. Il faut s'attendre à ce qu'il n'y ait plus du tout d'environnement Classic avec Mac OS X 10.5.x ni pour Mac Intel, ni pour Mac PPC ! ]

Il est toujours possible — via la commande du Finder Lire les informations — de forcer une application en code binaire universel à exécuter son code PPC et par conséquent à utiliser "Rosetta". Cela est même nécessaire si l'on veut utiliser des plug-ins exclusivement PPC avec une application en code binaire universel.

Qu'est-ce que tout cela signifie pour les programmeurs FB ?

Si vous distribuez ou vendez toujours des applications prédatant Mac OS X exlusivement PPC, il vous faut alors les adapter pour Mac OS X aussitôt que vous le pourrez. Ce processus de conversion est appelé "Carbonisation" dans le dialecte de FB.
[ À l'origine, dans la langue d'Apple, du code "Carbonisé" signifiait qu'il pouvait s'exécuter sur MacOS de 8.6 à 9.2.x et sur Mac OS X. FB ne garantit pas que votre code soit valide si vous le compilez pour "Carbon", mais il ne fait pas de doute que vous pourrez produire de belles applications exclusivement pour Mac OS X et c'est ce qui compte ici.]

Si vos applications s'exécutent nativement dans Mac OS X, alors, sur les Mac Intel, elles seront interprétées par "Rosetta".

Actuellement, FB ne génère pas de code binaire universel.

Quand verrons-nous une version de FB produisant des applications en code binaire universel ?

Cela requiert au moins deux changements essentiels dans le compilateur de FutureBASIC. D'abord, il doit être capable de générer du code binaire PPC au format Mach-O [ ce qui se fait toujours attendre ], ensuite, et plus demandant, il doit pouvoir créer aussi le code binaire correspondant pour Intel au format Mach-O. L'intégration finale — résultant en une application en code universel binaire — peut-être menée à bien à l'aide de “lipo”.

Est-ce qu'un compilateur FB adéquat pourra créer des applications en code binaire universel à partir de code FB existant ?

Catégoriquement non !
Il y a diverses opérations que le compilateur ne peut pas gérer. L'exemple le plus flagrant concerne les opérations sur les octets. Comme on le sait, l'ordre des octets avec les processeurs Intel est l'inverse de celui des processeurs Motorola. Pour une discussion approfondie et plus de détails sur ce type de difficultés, voyez “Universal Binary Programming Guidelines, Second Edition”. Apple nous dit que "Les développeurs Cocoa auront besoin de beaucoup moins d'ajustements dans leurs programmes que les développeurs Carbon dont le code a été porté de MacOS 9 à Mac OS X".
Et bien évidemment, les programmeurs FB sont des développeurs Carbon…

Herbie (28 Mars 2006)