Passer au contenu

Unix: du 32 au 64 bits , la migration n’est pas obligatoire

Sun et IBM et SCO lancent des Unix 64 bits. La transition coïncide avec l’arrivée de l’architecture 64 bits dIntel, qui concerne aussi HP. Sans précédent par son ampleur, la migration ne sera ni systématique ni transparente.

La migration d’Unix de 32 bits vers 64 bits n’est certes pas une nouveauté : Digital, HP et IBM ont franchi le pas en 1992 et 1997. Mais elle revient au goût du jour, avec le passage prochain à 64 bits du tandem SCO-IBM (projet Monterey) et de Sun (avec Solaris 7 en 1999). D’autant que cette phase de transition va être vécue par une immense base installée, qui passera de l’architecture d’Intel IA-32 (Pentium) à IA-64 (Itanium), que ce soit sous HP-UX, Solaris ou Monterey.UnixWare et Solaris (jusqu’à la version 7) étaient déjà partiellement 64 bits, notamment au niveau du système de fichiers ou des opérations arithmétiques. Mais le grand saut concerne l’espace d’adressage, dont la prise en compte impose une recompilation des applications, précédée d’une adaptation du code.

Conserver avant tout la compatibilité

Pour ce faire, les constructeurs proposent des utilitaires qui identifient les portions contenant des pointeurs mémoires. Tandis que les développeurs ont pris l’habitude d’écrire un code 32 bits propre, qui facilite la migration. Mais celle-ci est-elle une obligation ? Non, répondent en ch?”ur les fournisseurs. “Nombre d’applications ne seront sans doute pas portées “, affirme Jean-Marc Ferré, consultant Unix chez IBM. “Si l’espace d’adressage n’est pas un facteur critique, on recommande de rester en 32 bits “, estime Frédéric Léonetti, chef de produit HP 9000. “Beaucoup de clients préfèrent compiler en 32 bits, pour éviter d’augmenter la consommation mémoire “, renchérit Jean-François Gomez, responsable de la stratégie logiciel et architecture chez Sun.Cette unanimité rend utile la conservation d’une compatibilité. Il existe plusieurs formules selon lesquelles les applications 32 bits tirent plus ou moins profit du fait que les services du système d’exploitation sont, eux, 64 bits. La première consiste à recompiler en mode 64 bits, tout en conservant des entiers sur 32 bits. Il faut adapter le code, mais on profite alors d’un adressage 64 bits. C’est le mode LP 32 (pour pointeurs longs 32 bits) de Monterey. Avec son mode ILP 32 (comme entiers et pointeurs longs 32 bits), ce même Monterey offre la possibilité de recompiler en 64 bits les applications 32 bits sans toucher au code source. Les performances seront aussi bonnes qu’en 64 bits, mais l’espace d’adressage restera bloqué à 2 Go (ce qui correspond à un mot de 32 bits signés). Monterey permet en outre, comme HP-UX, de faire tourner sans recompilation, mais avec un faible gain, le code exécutable d’une application 32 bits. Tous deux s’appuient alors sur le mode IA-32 géré par Itanium. Tandis que les processeurs PA-Risc 64 bits supportent également les deux modes. Enfin, HP propose un mode ” magique ” unique, dans lequel une application 64 bits pour PA-Risc tourne sans recompilation sur Itanium, grâce à une traduction dynamique du flot d’instructions

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Lévy-Abégnoli