Discussion :

[koala01]

Salut,

Cela n'aura échappé à personne, les jours des processeurs 32 bits sont comptés du coté des PC...

Pour ceux qui s'y intéressent, il est même évident que les différents systèmes d'exploitation partent résolument vers des implémentations 64 bits.

Ayant récemment acquis un(e bête de course de) PC en remplacement de mon antique Athlon 1700 XP, je me suis, tout naturellement, tourné vers les versions 64 bits pour les systèmes d'exploitation (vista et ubuntu).

Le moment est donc opportun pour moi d'essayer de faire un peu le point sur la manière les différents outils gèrent ce doublement de capacité des registres.

Il me semble évident que, sous linux, la situation est simple: si on prend un environnement 64 bits, l'ensemble des outils (dont Gcc) va respecter ce choix, tout en donnant la possibilité, en cas de besoin, de compiler une application 32bits.

Mais j'aimerais avoir, c'est l'état des lieux sous windows (et sous vista en particulier):

• Comment vista gère-t-il le 64 bits
• Existe-t-il des compilateurs capables de fournir des applications 64 bits
• Quelqu'un a-t-il réussi à compiler Gcc (que ce soit sous Cygwin ou sous le vocable MinGW) de manière à ce qu'il fournisse des applications 64 bits (mes différentes recherches sur le sujet ne m'ont pas permis de trouver des réponses récentes)
• Toute autre question à laquelle je n'aurais pas pensé vu l'heure tardive

Merci d'avance à tous ceux qui pourront apporter un élément de réponse

koala01

[nicroman]

Salut,

Vista x64 tourne en 64 bits, avec une surcouche (SysWOW64) pour faire tourner les programmes 32 bits... Exit le 16 bits donc (SysWOW32 sur les très vieux PCs) !
En fait, le processeur ne *voit* que du 32 bits dans le cas d'une application 32 bits, et tout se déroule comme si un windows 32 bits était installé (avec une limitation a 4GO de RAM si le flag LARGEADDRESSAWARE est présent).

Donc:
- Les drivers doivent être exclusivement 64 bits. Ce qui ne pose aucun problême pour la majeure partie des acteurs importants... Mais on trouve quelques récalcitrants pour des périphériques "secondaires" (imprimantes, scanners, ...).
- Tous les compilateurs sérieux peuvent compiler pour 32 ou 64 bits à volonté sur un système 32 bits (et donc à forciori 64 bits) étant donné qu'ils sont eux même des applications 32 bits ! Par contre, inutile de débugger du 64 bits sur un OS 32 bits !
- Aux dernières nouvelles, gcc compilait par défaut pour l'OS (64 bits sous un OS 64bits, et 32 bits sous un OS 32 bits), il faut override avec -m32 ou -m64 IIRC.


Maintenant, quant à installer Vista x64... je serai toi... j'installerai Windows 7 x64 !

[Goten]

Moi je pense surtout qu'il faut pas enterré aussi vite les OS 32 bits... On va voir avec 7 mais je trouve pas que le gain apporté soit flagrant, si ce n'est la limite sur la mémoire...

[Ubiquité]

La surcouche bouffe des ressources, des benchs montre que certaines appli 32 sur vista 64 avec 4Go de ram tourne moins vite que sur vista 32 avec 2Go.

[nicroman]

Moi je pense surtout qu'il faut pas enterré aussi vite les OS 32 bits... On va voir avec 7 mais je trouve pas que le gain apporté soit flagrant, si ce n'est la limite sur la mémoire...

Je crois que le but de ce thread n'est pas de savoir si c'est mieux ou pas mieux, mais comment c'est géré, et quel outil utiliser...

[koala01]

D'abord, je vous présente mes excuses... je croyais avoir posté plus tot une réponse, mais, visiblement, j'ai loupé la dernière étape (le bouton "envoyer"

Salut,

Vista x64 tourne en 64 bits, avec une surcouche (SysWOW64) pour faire tourner les programmes 32 bits... Exit le 16 bits donc (SysWOW32 sur les très vieux PCs) !
En fait, le processeur ne *voit* que du 32 bits dans le cas d'une application 32 bits, et tout se déroule comme si un windows 32 bits était installé (avec une limitation a 4GO de RAM si le flag LARGEADDRESSAWARE est présent).

Donc:
- Les drivers doivent être exclusivement 64 bits. Ce qui ne pose aucun problême pour la majeure partie des acteurs importants... Mais on trouve quelques récalcitrants pour des périphériques "secondaires" (imprimantes, scanners, ...).

Oui, cela, je l'avais effectivement compris...

Mais c'est une bonne chose, dans le cadre de l'état des lieux, de commencer par ce point

- Tous les compilateurs sérieux peuvent compiler pour 32 ou 64 bits à volonté sur un système 32 bits (et donc à forciori 64 bits) étant donné qu'ils sont eux même des applications 32 bits ! Par contre, inutile de débugger du 64 bits sur un OS 32 bits !

Cela me semblait également bien clair, mais, là aussi, il n'est pas inutile d'enfoncer cette porte ouverte

- Aux dernières nouvelles, gcc compilait par défaut pour l'OS (64 bits sous un OS 64bits, et 32 bits sous un OS 32 bits), il faut override avec -m32 ou -m64 IIRC.

Sous linux, il semble que ce soit effectivement le cas...

Ce qui m'intéresse réellement, c'est son comportement du fait de son portage sous windows, et sous MinGW tout particulièrement...

En effet, voilà ce dont je suis sur (ou du moins, ce dont je crois être sur du fait des informations dont je dispose):

• MinGW est compilé avec le triplet 386 (ou 686)-pc-mingw32
• mingw32 est normalement destiné à faire place à mingw pour ne pas donner l'impression que l'on compile en 32bits uniquement, mais ce n'est pas forcément un problème (ce qui importe, c'est que nous sachions que c'est compiler pour MinGW )
• Par contre, la première partie du triplet indique clairement que l'architecture envisagée est destinée à un 3x86 ou à un pentium II maximum... (donc, par définition, un processeur 32 bits)
• MSYS fonctionne (sauf information contraire) en 32 bis (bien qu'il semblerait qu'ils aient sorti une nouvelle dll permettant de travailler nativement en 64 bits, mais c'est à vérifier)
• une chose est sure, lorsque l'on essaye de passer l'argument -m64 à gcc, nous obtenons un joli "sorry, unimplemented: 64-bit mode not compiled in", mais c'est peut être (voire surement) parce que binutils (et particulièrement ld) n'est pas compilé avec le support 64 bits.
• Dans la version officielle de _mingw.h, long long est un __int64, mais il me semble que sous linux ce serait encore bien un__int128 non
• Dans un trunk de la crt, dont l'objectif est de passer en 64 bits, on trouve, entre autre, un test sur _WIN64 et les définitions (préprocesseurs) de _ptr32 et de _ptr64 et même dans un test un typedef de unsigned __int64 en size_t
• Lorsque je tente de compiler ce trunk de mingw-runtime, je me heurte à l'absence de nombreuses bibliothèques (dont lib6to4svc n'est que la première absente)

Bref, tout ceci me semble indiquer que, par défaut, MinGW est un compilateur... 32bits only (bien que Gcc et consort soient prévus pour supporter indiféremment le 32 et le 64bits).

Maintenant, quant à installer Vista x64... je serai toi... j'installerai Windows 7 x64 !

Je ne m'aventurerai pas dans ce débat, pour éviter les trolls

La surcouche bouffe des ressources, des benchs montre que certaines appli 32 sur vista 64 avec 4Go de ram tourne moins vite que sur vista 32 avec 2Go.

C'est l'une des raisons pour lesquelles je souhaiterais disposer d'un compilateur qui, par défaut, compilera mes applications en 64 bits, vu que tout sur ma machine me permet de les faire tourner raisonnablement

Moi je pense surtout qu'il faut pas enterré aussi vite les OS 32 bits... On va voir avec 7 mais je trouve pas que le gain apporté soit flagrant, si ce n'est la limite sur la mémoire...

Je ne suis pas d'accord avec toi sur ce coup...

Sans vouloir lancer le troll, lorsque l'on remarque que les linux 64 bits le sont "jusqu'au bout des ongles", et que la vitesse de compilation en natif est très largement supérieure à ce que l'on obtiens avec les mêmes outils sous windows, je peux t'assurer qu'il y a de fortes chances pour que le 32bits ne vive finalement plus très longtemps (ou du moins soit littéralement absent des développements futurs prévus pour tourner en 64 bits)...

Il ne faut pas oublier non plus que le PC n'est en réalité qu'une "niche" malgré tout très peu représentée sur l'ensemble du parc informatique mondial et que d'autres architectures sont déjà "full 64 bits" depuis des années, pour ne pas dire des décennies

Je crois que le but de ce thread n'est pas de savoir si c'est mieux ou pas mieux, mais comment c'est géré, et quel outil utiliser...

Exactement

Mais je me rend compte que, la fatigue aidant, je n'ai peut être pas exposé mes question de manière particulièrement efficace

Je vais donc les exprimer plus clairement

Maintenant que l'état des lieux est fait en ce qui concerne windows, pourriez vous me dire s'il existe une différence au niveau de l'API (ou de l'ABI) windows si l'on excepte les inévitables ajouts de bibliothèques et les instructions de compilation conditionnelle entre la crt 32bits et la crt 64

Quelqu'un aurait-il une idée claire et actuelle (si elle se base sur un message paru sur la ML en 2007, ca risque de manquer d'intérêt... quoi que) sur la capacité des bibliothèques connues sous les nom de win32api et de mingw-runtime à supporter le mode de compilation 64 bits

Quelqu'un a-t-il déjà réussi à compiler Gcc dans sa version MinGW de manière à ce que, par défaut, il produise des exécutables 64 bits

Enfin, quelles versions des autres compilateurs (qu'ils soient de chez borland, intel microsoft ou d'ailleurs) sont-elles capables de générer, par défaut, des applications 64 bits sous windows

[nicroman]

Cela me semblait également bien clair, mais, là aussi, il n'est pas inutile d'enfoncer cette porte ouverte

Désolé koala... j'essayais de faire une réponse aussi simple que possible pour tout le monde, sans trop m'attarder à ton cas particulier qui est déjà bien avancé dans le sujet... Toute mes scuses !

Mes connaissances de mingw sont vraiment tellement légères... je préfère lancer mon nunux sous machine virtuelle...

Dans la version officielle de _mingw.h, long long est un __int64, mais il me semble que sous linux ce serait encore bien un__int128 non

En fait.. on s'en fout non ? tant que sizeof(long long) >= sizeof(long) c'est tout ce qui importe.
Il me semble d'ailleurs qu'il y a une différence entre le monde linux (sizeof(int)=32, sizeof(long)=64) et windows (sizeof(int)=sizeof(long)=64), mais je peux me tromper, comme j'utilise principalement des __int## ...

C'est l'une des raisons pour lesquelles je souhaiterais disposer d'un compilateur qui, par défaut, compilera mes applications en 64 bits, vu que tout sur ma machine me permet de les faire tourner raisonnablement

Ben... sous Windows.... Visual ?
Sinon... virtual machine et gcc....

Sans vouloir lancer le troll, lorsque l'on remarque que les linux 64 bits le sont "jusqu'au bout des ongles", et que la vitesse de compilation en natif est très largement supérieure à ce que l'on obtiens avec les mêmes outils sous windows, je peux t'assurer qu'il y a de fortes chances pour que le 32bits ne vive finalement plus très longtemps (ou du moins soit littéralement absent des développements futurs prévus pour tourner en 64 bits)...

C'est également vrai sur PC... quand on parle d'un OS 64 bits, cela veut dire que le noyau est en 64 bits, donc toute la partie hardware / piles réseaux / schedulers
D'ailleurs, si il y a bien un domaine ou Vista 64 excelle (par rapport à XP32 ou XP64 ou Vista32), c'est bien les applications multi-processeurs (ray-tracers, compilateurs, ...).
Le gros probleme de Vista était que les premiers à upgrader ont été les geeks (comme moi), et du coup, il n'ont vu que le fait que Crysis perdait 2fps sur les 12fps qu'ils avaient, et les gens en sont restés là.
Toute la partie réseau a été revue, la gestion des I/O, le scheduler de taches entierement refait...
Mais bon... là on diverge...

Il ne faut pas oublier non plus que le PC n'est en réalité qu'une "niche" malgré tout très peu représentée sur l'ensemble du parc informatique mondial et que d'autres architectures sont déjà "full 64 bits" depuis des années, pour ne pas dire des décennies

Et oui.... on parle bien de décennies.... à ma naissance (1970) il y avait déjà des processeurs 64 bits (et les OS dessus).
Le premier processeur "grand public" en 64 bits, était le PowerPC 620 (aka G2 en 1997) mais que personne n'a vraiment utilisé... puis les PowerPC 970 (aka G5 en 2002), mais il aura fallu MaxOS 10.5 (en 2007) pour que le 64 bits soit disponible sur ceux ci

[koala01]

Désolé koala... j'essayais de faire une réponse aussi simple que possible pour tout le monde, sans trop m'attarder à ton cas particulier qui est déjà bien avancé dans le sujet... Toute mes scuses !

Il ne faut pas t'excuser, je saluais effectivement (malgré les apparences) la présence des explications de base

Et oui.... on parle bien de décennies.... à ma naissance (1970) il y avait déjà des processeurs 64 bits (et les OS dessus).
Le premier processeur "grand public" en 64 bits, était le PowerPC 620 (aka G2 en 1997) mais que personne n'a vraiment utilisé... puis les PowerPC 970 (aka G5 en 2002), mais il aura fallu MaxOS 10.5 (en 2007) pour que le 64 bits soit disponible sur ceux ci

En fait, je pensais principalement à certaines architectures qui ne sont absolument pas orientées vers le grand publique (comme ASxxx ou MainFrame et autres )

Mais il est, à mon sens, évident que l'on observera un phénomène identique à ce qui s'est passé lorsque les processeurs 32bits sont apparus: l'abandon de "l'ancienne norme" (16 bits à l'époque) a finalement été très rapide

Et le phénomène risque, selon moi, d'être amplifié par le fait que les prix du matériel ont été tirés vers le bas

[Invité]

Le compilateur Intel produit du code 64 bits pour Windows et Linux. Chez Borland, il n'y a pas de compilation 64 bits (ni en C, ni en delphi), à ma connaissance, et je doute qu'on en voit une rapidement.

Francois