Discussion :

[grunt2000]

Bonjour,

C'est une question très générale que je pose, pour me représenter le problème concret que rencontrent les développeurs de pilotes de périphériques.

J'ai déjà fait de l'assembleur sur PC. Au temps où c'était nécessaire en 16 bits (programmation VGA). Mais même si aujourd'hui les pilotes sont écrits en C ou C++ certainement, le mode 64 bits, lui, est issu du processeur et il faut se pencher dessus.

Il est de notoriété publique que le passage en mode 64 bits sous Windows se fait, mais avec quelques souffrances. Tel driver qui n'est pas prêt, fonctionne inégalement vis-à-vis de son équivalent 32 bits. Bien sûr, avec le temps, tout s'aplanira et se résoudra.

Mais pourquoi tous ces troubles?
Le passage en 64 bits, ce n'est pas seulement des registres qui s'accroissent en taille et quelques mnémoniques supplémentaires?

Pourquoi le portage des drivers en 64 bits induit-il une certaine instabilité?
Sont-ce des nouveautés induites par le mode 64 bits (que je ne connais pas) qui provoquent cela?


En vous remerciant pour vos explications,

Grunt.

[Obsidian]

Pour Windows en particulier, je ne sais pas (Linux fonctionne très bien en 64 bits, depuis longtemps), mais d'une manière générale, passer un O.S. entier de 32 à 64 bits ne se fait pas simplement en le recompilant. Ou plutôt, le problème ne situe pas là.

Si tu ne réécris pas le logiciel en entier, il faut recetter tous ses composants pour s'assurer que la migration n'a pas causé d'effets de bord, ni de régression. Et vérifier l'intégralité du produit cartésien des différents modules d'un O.S. entier est un travail considérable ! À la limite, c'est plus facile dans le monde du libre car, d'une part, le public a un intérêt pour le 64 bits (plus marqué, en tout cas, que celui des utilisateurs de Windows dans les bureaux), et parce que l'audit est beaucoup plus vaste.

J'ai déjà fait de l'assembleur sur PC. Au temps où c'était nécessaire en 16 bits (programmation VGA). Mais même si aujourd'hui les pilotes sont écrits en C ou C++ certainement, le mode 64 bits, lui, est issu du processeur et il faut se pencher dessus.

En fait, le passage de « 16 à 32 bits » n'était pas un simple changement de format. Le passage au 32 bits sur x86 a consacré le mode protégé, et de nouveaux modes d'adressages ont fait leur apparition. Cela a donc introduit une manière totalement différente de concevoir les logiciels. Ce serait comme passer du C au C++, par exemple.

En ce qui concerne le passage du 32 bits au 64, il n'y a pas de gros changement, en effet. Mais pour être sûr que tout fonctionne du premier coup, il faudrait pouvoir garantir que le moindre morceau de code a été écrit dans un C irréprochable et parfaitement portable. Or, la portabilité est loin d'être une priorité lorsque l'on développe un O.S. grand public dont le PC occupe 98% du marché (chiffre annoncé au pif).

Par exemple, bon nombre de gens considèrent qu'un char = 8 bits, et un int = 32 bits. Or, la définition du char est « un entier suffisamment grand pour représenter un caractère du jeu de base » utilisé par le compilateur. Comme c'est généralement l'ASCII — qui lui-même code les caractères sur 7 bits et pas huit — le compilateur définit généralement un char sur un octet, ce qui arrange tout le monde, mais n'est pas normalisé en tant que tel.

En ce qui concerne les entiers, la règle C est « sizeof(short int) ≤ sizeof(int) ≤ sizeof(long int) » avec short int = 16 bits au minimum, long int au minimum 32, et long long int 64 au minimum. Un compilo aurait tout-à-fait le droit de déclarer tous ces entiers comme étant longs de 64 bits. Maintenant, considère le code suivant :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
signed int x;
 
x=(signed int)0xffffffff;

Si « x » est un entier 32 bits, il vaudra -1 à l'issue de cette procédure. Si c'est un 64 bits, il vaudra 4294967295 et sera un nombre positif tout-à-fait ordinaire, localisé vers le début de la gamme des nombres représentables. Si après j'écris :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

if (x>0) printf ("Ok, ça marche.\n");

Là, on comprend pourquoi un code à peu près propre qui fonctionne depuis des années et qui n'a pas été modifié peut se mettre à planter d'une façon qui peut sembler complètement aléatoire.

Enfin, et c'est probablement le plus problématique : Microsoft ne peut probablement pas TOUT recompiler : beaucoup de logiciels utilisés à travers le monde sous Windows viennent de tierces parties, et les sources ne sont pas disponibles comme dans le libre. Il faut donc que l'OS 64 bits compose avec les binaires 32, comme c'est déjà le cas sous Linux, et autres. Au niveau du code machine, ça ne pose pas de problème puisque le CPU est déjà fait pour. Mais au niveau de l'interaction avec le système, cela t'oblige à fournir des versions 32 bits et 64 bits de chaque bibliothèque, et une interface d'adaptation 32↔64 au niveau des appels système.

[grunt2000]

Bravo!

Ça c'est un tour du problème complet et clair!

Merci !