Cherchant à acheter un processeur, je me suis aperçu que les "64 bits"
sont à la mode en ce moment. Ce qui veut dire que je vais sans doute
devoir, à moyen terme, recompiler pas mal de mes applications en 64
bits.
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des
problèmes récurrents ? J'imagine qu'à part ces <CENSURÉ> de formats de
fichiers binaires, ça se fait de façon assez transparente, mais
sait-on jamais...
Accessoirement, je suppose que typiquement, sur une telle
architecture, "long" et "int" sont codés sur 64 bits, mais qu'en
est-il de "short" ? Et, du coup, peut-on avoir des entiers de 8, 16 et
32 bits ?
Valà valà, merci pour vos réactions...
-- Fabien, qui pense tout à coup au 64 bits parce que c'est à la mode
;-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Richard Delorme
Bonjour,
Cherchant à acheter un processeur, je me suis aperçu que les "64 bits" sont à la mode en ce moment. Ce qui veut dire que je vais sans doute devoir, à moyen terme, recompiler pas mal de mes applications en 64 bits.
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des problèmes récurrents ? J'imagine qu'à part ces <CENSURÉ> de formats de fichiers binaires, ça se fait de façon assez transparente, mais sait-on jamais...
Accessoirement, je suppose que typiquement, sur une telle architecture, "long" et "int" sont codés sur 64 bits, mais qu'en est-il de "short" ? Et, du coup, peut-on avoir des entiers de 8, 16 et 32 bits ?
Valà valà, merci pour vos réactions...
La bonne réponse est : « ça dépend » :-) Le modèle le plus courant pour les Unix est : char 8 bits short 16 bits int 32 bits long 64 bits pointeur 64 bits En résumé c'est le modèle : I32LP64
Microsoft préfère : char 8 bits short 16 bits int 32 bits long 32 bits pointeur 64 bits alias le modèle IL32P64
Evidemment d'autres combinaisons sont possibles, histoire d'ajouter à la confusion :-(
Cherchant à acheter un processeur, je me suis aperçu que les "64 bits"
sont à la mode en ce moment. Ce qui veut dire que je vais sans doute
devoir, à moyen terme, recompiler pas mal de mes applications en 64
bits.
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des
problèmes récurrents ? J'imagine qu'à part ces <CENSURÉ> de formats de
fichiers binaires, ça se fait de façon assez transparente, mais
sait-on jamais...
Accessoirement, je suppose que typiquement, sur une telle
architecture, "long" et "int" sont codés sur 64 bits, mais qu'en
est-il de "short" ? Et, du coup, peut-on avoir des entiers de 8, 16 et
32 bits ?
Valà valà, merci pour vos réactions...
La bonne réponse est : « ça dépend » :-)
Le modèle le plus courant pour les Unix est :
char 8 bits
short 16 bits
int 32 bits
long 64 bits
pointeur 64 bits
En résumé c'est le modèle : I32LP64
Microsoft préfère :
char 8 bits
short 16 bits
int 32 bits
long 32 bits
pointeur 64 bits
alias le modèle IL32P64
Evidemment d'autres combinaisons sont possibles, histoire d'ajouter à la
confusion :-(
Cherchant à acheter un processeur, je me suis aperçu que les "64 bits" sont à la mode en ce moment. Ce qui veut dire que je vais sans doute devoir, à moyen terme, recompiler pas mal de mes applications en 64 bits.
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des problèmes récurrents ? J'imagine qu'à part ces <CENSURÉ> de formats de fichiers binaires, ça se fait de façon assez transparente, mais sait-on jamais...
Accessoirement, je suppose que typiquement, sur une telle architecture, "long" et "int" sont codés sur 64 bits, mais qu'en est-il de "short" ? Et, du coup, peut-on avoir des entiers de 8, 16 et 32 bits ?
Valà valà, merci pour vos réactions...
La bonne réponse est : « ça dépend » :-) Le modèle le plus courant pour les Unix est : char 8 bits short 16 bits int 32 bits long 64 bits pointeur 64 bits En résumé c'est le modèle : I32LP64
Microsoft préfère : char 8 bits short 16 bits int 32 bits long 32 bits pointeur 64 bits alias le modèle IL32P64
Evidemment d'autres combinaisons sont possibles, histoire d'ajouter à la confusion :-(
Cherchant à acheter un processeur, je me suis aperçu que les "64 bits" sont à la mode en ce moment. Ce qui veut dire que je vais sans doute devoir, à moyen terme, recompiler pas mal de mes applications en 64 bits.
Je ne connais pas ton domaine. Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)? Si non, pourquoi veux-tu y passer? A ma connaissance, les OS 64 bits peuvent executer les executables 32 bits et la raison principale de vouloir passer en 64 bits c'est d'augmenter l'espace adressable. (En general, ca diminue la vitesse et ca augmente la quantite de memoire necessaire).
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des problèmes récurrents ?
Il y a au moins trois modeles de 64 bits, donc a ma connaissance deux sont utilises de nos jours: int long pointeur long long short ILP64 64 64 64 64 ? LP64 32 64 64 64 16 LL64 32 32 64 64 16
Le premier a ete tente si j'ai bonne memoire par les DEC sur les premiers alpha mais le probleme de ne pas avoir des types pour toutes les tailles (short 16, manque 32 et short 32 manque 16) a fait que le second est le modele dominant des Unix, le troisieme celui choisi par Windows.
Le probleme principal est la supposition que certains types sont de meme taille (windows favorise int=long, unix long=pointeur). Pour bien nettoyer le code il faut utiliser des intptr_t et uintptr_t.
Un probleme parfois est qu'en changeant l'ordre de champs on arrive a diminuer la taille de structures (l'alignement des types 64 bits est generalement sur 8 octets).
Dans du code vieux et C like, il y a des tailles de buffer fixes qui supposent qu'on formatte des entiers de 32 bits et on se retrouve avec des buffer overflow en formattant un long de 64 bits qui contient des valeurs superieures a une certaine borne (ce qui n'arrive naturellement pas dans le jeux de test qui au depart n'a que des donnees qui tiennent sur 32 bits...)
Ce sont les choses auxquelles je pense, mais si les programmes sur lesquelles je travaille tourne en 64 bits, je n'ai pas ete implique dans le travail initial qui a consiste a les faire fonctionner, donc il doit y avoir d'autre choses (et je suis certains qu'ils ne tourneraient pas sous Windows 64 bits meme quand ils tournent sous Windows 32 bits).
J'imagine qu'à part ces <CENSURÉ> de formats de fichiers binaires, ça se fait de façon assez transparente, mais sait-on jamais...
Je ne m'occupe pas d'IO. Si c'est bien concu je ne vois guere de probleme: on change la revision et a la lecture on a simplement une variable qui controle le nombre d'octets a lire suivant la revision. Naturellement si on se contente de dump brut de la memoire... mais alors il y a aussi des problemes sous-jacent en 32 bits.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
Cherchant à acheter un processeur, je me suis aperçu que les "64
bits" sont à la mode en ce moment. Ce qui veut dire que je vais sans
doute devoir, à moyen terme, recompiler pas mal de mes applications
en 64 bits.
Je ne connais pas ton domaine. Est-ce qu'elles en profiteraient? Si
oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand
meme disponible depuis plus de dix ans)? Si non, pourquoi veux-tu y
passer? A ma connaissance, les OS 64 bits peuvent executer les
executables 32 bits et la raison principale de vouloir passer en 64
bits c'est d'augmenter l'espace adressable. (En general, ca diminue
la vitesse et ca augmente la quantite de memoire necessaire).
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des
problèmes récurrents ?
Il y a au moins trois modeles de 64 bits, donc a ma connaissance deux
sont utilises de nos jours:
int long pointeur long long short
ILP64 64 64 64 64 ?
LP64 32 64 64 64 16
LL64 32 32 64 64 16
Le premier a ete tente si j'ai bonne memoire par les DEC sur les
premiers alpha mais le probleme de ne pas avoir des types pour toutes
les tailles (short 16, manque 32 et short 32 manque 16) a fait que le
second est le modele dominant des Unix, le troisieme celui choisi par
Windows.
Le probleme principal est la supposition que certains types sont de
meme taille (windows favorise int=long, unix long=pointeur). Pour
bien nettoyer le code il faut utiliser des intptr_t et uintptr_t.
Un probleme parfois est qu'en changeant l'ordre de champs on arrive a
diminuer la taille de structures (l'alignement des types 64 bits est
generalement sur 8 octets).
Dans du code vieux et C like, il y a des tailles de buffer fixes qui
supposent qu'on formatte des entiers de 32 bits et on se retrouve avec
des buffer overflow en formattant un long de 64 bits qui contient des
valeurs superieures a une certaine borne (ce qui n'arrive
naturellement pas dans le jeux de test qui au depart n'a que des
donnees qui tiennent sur 32 bits...)
Ce sont les choses auxquelles je pense, mais si les programmes sur
lesquelles je travaille tourne en 64 bits, je n'ai pas ete implique
dans le travail initial qui a consiste a les faire fonctionner, donc
il doit y avoir d'autre choses (et je suis certains qu'ils ne
tourneraient pas sous Windows 64 bits meme quand ils tournent sous
Windows 32 bits).
J'imagine qu'à part ces <CENSURÉ> de formats de fichiers binaires,
ça se fait de façon assez transparente, mais sait-on jamais...
Je ne m'occupe pas d'IO. Si c'est bien concu je ne vois guere de
probleme: on change la revision et a la lecture on a simplement une
variable qui controle le nombre d'octets a lire suivant la revision.
Naturellement si on se contente de dump brut de la memoire... mais
alors il y a aussi des problemes sous-jacent en 32 bits.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Cherchant à acheter un processeur, je me suis aperçu que les "64 bits" sont à la mode en ce moment. Ce qui veut dire que je vais sans doute devoir, à moyen terme, recompiler pas mal de mes applications en 64 bits.
Je ne connais pas ton domaine. Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)? Si non, pourquoi veux-tu y passer? A ma connaissance, les OS 64 bits peuvent executer les executables 32 bits et la raison principale de vouloir passer en 64 bits c'est d'augmenter l'espace adressable. (En general, ca diminue la vitesse et ca augmente la quantite de memoire necessaire).
Est-ce que quelqu'un a déjà fait ce genre de choses, et a repéré des problèmes récurrents ?
Il y a au moins trois modeles de 64 bits, donc a ma connaissance deux sont utilises de nos jours: int long pointeur long long short ILP64 64 64 64 64 ? LP64 32 64 64 64 16 LL64 32 32 64 64 16
Le premier a ete tente si j'ai bonne memoire par les DEC sur les premiers alpha mais le probleme de ne pas avoir des types pour toutes les tailles (short 16, manque 32 et short 32 manque 16) a fait que le second est le modele dominant des Unix, le troisieme celui choisi par Windows.
Le probleme principal est la supposition que certains types sont de meme taille (windows favorise int=long, unix long=pointeur). Pour bien nettoyer le code il faut utiliser des intptr_t et uintptr_t.
Un probleme parfois est qu'en changeant l'ordre de champs on arrive a diminuer la taille de structures (l'alignement des types 64 bits est generalement sur 8 octets).
Dans du code vieux et C like, il y a des tailles de buffer fixes qui supposent qu'on formatte des entiers de 32 bits et on se retrouve avec des buffer overflow en formattant un long de 64 bits qui contient des valeurs superieures a une certaine borne (ce qui n'arrive naturellement pas dans le jeux de test qui au depart n'a que des donnees qui tiennent sur 32 bits...)
Ce sont les choses auxquelles je pense, mais si les programmes sur lesquelles je travaille tourne en 64 bits, je n'ai pas ete implique dans le travail initial qui a consiste a les faire fonctionner, donc il doit y avoir d'autre choses (et je suis certains qu'ils ne tourneraient pas sous Windows 64 bits meme quand ils tournent sous Windows 32 bits).
J'imagine qu'à part ces <CENSURÉ> de formats de fichiers binaires, ça se fait de façon assez transparente, mais sait-on jamais...
Je ne m'occupe pas d'IO. Si c'est bien concu je ne vois guere de probleme: on change la revision et a la lecture on a simplement une variable qui controle le nombre d'octets a lire suivant la revision. Naturellement si on se contente de dump brut de la memoire... mais alors il y a aussi des problemes sous-jacent en 32 bits.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet :
Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Note que sous Windows, c'est le 32 bits qui est disponible depuis une dizaine d'années ;-)
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Est-ce qu'elles en profiteraient? Si
oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand
meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de
RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici
un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de
RAM, d'où des pointeurs de 64 bits.
Note que sous Windows, c'est le 32 bits qui est disponible depuis une
dizaine d'années ;-)
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet :
Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Note que sous Windows, c'est le 32 bits qui est disponible depuis une dizaine d'années ;-)
François Boutines
"Fabien LE LEZ" a écrit dans le message de news:
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet :
Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Ou un tout nouveau système de segmentation 32:32 :o)
plus sérieusement (mais guerre plus) considérez cette classe fraction :
http://csserver.evansville.edu:8888/roberts/32
diriez-vous qu'elle passe la construction (pour tous les paramètres possibles) sur une plateforme ou int fait 64 bits ? Bien entendu, le compilateur n'y est pour rien, c'est une faute d'implémentation (dans gcd), mais c'est aussi un exemple de programme qui marchait (ou marchouillait) mais ne marche plus...
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
5ptsf0h15qvpfpcqahtvik1aeea3grlnhb@4ax.com...
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Est-ce qu'elles en profiteraient? Si
oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand
meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de
RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici
un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de
RAM, d'où des pointeurs de 64 bits.
Ou un tout nouveau système de segmentation 32:32 :o)
plus sérieusement (mais guerre plus) considérez cette classe fraction :
http://csserver.evansville.edu:8888/roberts/32
diriez-vous qu'elle passe la construction (pour tous les paramètres
possibles) sur une plateforme ou int fait 64 bits ?
Bien entendu, le compilateur n'y est pour rien, c'est une faute
d'implémentation (dans gcd), mais c'est aussi un exemple de programme qui
marchait (ou marchouillait) mais ne marche plus...
On 21 Jul 2004 09:18:05 +0200, Jean-Marc Bourguet :
Est-ce qu'elles en profiteraient? Si oui, pourquoi elles n'en profitent pas deja (le 64 bits c'est quand meme disponible depuis plus de dix ans)?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Ou un tout nouveau système de segmentation 32:32 :o)
plus sérieusement (mais guerre plus) considérez cette classe fraction :
http://csserver.evansville.edu:8888/roberts/32
diriez-vous qu'elle passe la construction (pour tous les paramètres possibles) sur une plateforme ou int fait 64 bits ? Bien entendu, le compilateur n'y est pour rien, c'est une faute d'implémentation (dans gcd), mais c'est aussi un exemple de programme qui marchait (ou marchouillait) mais ne marche plus...
Christophe de VIENNE
Fabien LE LEZ wrote:
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le système est donc capable d'adresser plus de 4Go. Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une plateforme 32bits, d'adresser plus de 4Go ?
A+
Christophe
-- Christophe de Vienne
Fabien LE LEZ wrote:
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de
RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici
un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de
RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est
capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le
système est donc capable d'adresser plus de 4Go.
Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une
plateforme 32bits, d'adresser plus de 4Go ?
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le système est donc capable d'adresser plus de 4Go. Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une plateforme 32bits, d'adresser plus de 4Go ?
A+
Christophe
-- Christophe de Vienne
Jean-Marc Bourguet
Christophe de VIENNE writes:
Fabien LE LEZ wrote:
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le système est donc capable d'adresser plus de 4Go. Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une plateforme 32bits, d'adresser plus de 4Go ?
Tout depend de ce qu'on appelle un processeur 32 bits. La definition que je prefere est c'est un processeur dont les registres de donnees ont 32 bits.
Avec cette definition, on peut avoir un espace d'adressage de plus de 32 bits (utilise la segmentation avec un OS qui remappe les segments quand c'est necessaire sur un ia32 par exemple et il est courant pour les 8 bits de pouvoir adresser 64K et les 16 bits de pouvoir adresser plus que ca -- 20bits d'adresse pour le 8086 par exemple).
Cette definition correspond assez bien avec l'usage que j'ai vu pour une grande classe de processeurs (y compris des machines adressables par mots avec des mots de 36 bits et un espace d'adressage de 18 bits) mais elle n'est pas reellement universelle.
Les processeurs les plus repandus que j'ai vu designe autrement que je ne le fait sont le 8088 (8bits comme sont bus donnee externe) 68000 (vu qualifie de 16 bits), le 68008 (vu qualifie de 8 bits). Ces deux processeurs sont d'ailleurs amusant de ce point de vue (le 68000 a des registres de 32 bits, un bus d'adresse de 24 bits, a des bus donnee interne et externe de 16 bits, le 68008 a des registres de 32 bits, un bus d'adresse de 20 bits, a des bus donnee interne de 16 bits et externe de 8 bits). Apparememnt la taille du bus de donnee externe est l'autre grand candidats, mais avec les architectures actuelles on aurait donc des processeur 128 ou 256 bits...
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Christophe de VIENNE <cdevienne@alphacent.com> writes:
Fabien LE LEZ wrote:
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de
RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici
un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de
RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est
capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le
système est donc capable d'adresser plus de 4Go.
Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une plateforme
32bits, d'adresser plus de 4Go ?
Tout depend de ce qu'on appelle un processeur 32 bits. La definition
que je prefere est c'est un processeur dont les registres de donnees
ont 32 bits.
Avec cette definition, on peut avoir un espace d'adressage de plus de
32 bits (utilise la segmentation avec un OS qui remappe les segments
quand c'est necessaire sur un ia32 par exemple et il est courant pour
les 8 bits de pouvoir adresser 64K et les 16 bits de pouvoir adresser
plus que ca -- 20bits d'adresse pour le 8086 par exemple).
Cette definition correspond assez bien avec l'usage que j'ai vu pour
une grande classe de processeurs (y compris des machines adressables
par mots avec des mots de 36 bits et un espace d'adressage de 18 bits)
mais elle n'est pas reellement universelle.
Les processeurs les plus repandus que j'ai vu designe autrement que je
ne le fait sont le 8088 (8bits comme sont bus donnee externe) 68000
(vu qualifie de 16 bits), le 68008 (vu qualifie de 8 bits). Ces deux
processeurs sont d'ailleurs amusant de ce point de vue (le 68000 a des
registres de 32 bits, un bus d'adresse de 24 bits, a des bus donnee
interne et externe de 16 bits, le 68008 a des registres de 32 bits, un
bus d'adresse de 20 bits, a des bus donnee interne de 16 bits et
externe de 8 bits). Apparememnt la taille du bus de donnee externe
est l'autre grand candidats, mais avec les architectures actuelles on
aurait donc des processeur 128 ou 256 bits...
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je travaille sur PC, et sur ce genre de machines, la barre des 4 Go de RAM commence à être atteinte. Donc, il n'est pas impossible que d'ici un an ou deux, je commence à avoir besoin d'accéder à plus de 4 Go de RAM, d'où des pointeurs de 64 bits.
Je me pose une question métaphysique du coup : Sous linux, le noyau est capable de gérer jusqu'à 64Go de RAM, avec un processeur 32bits... Le système est donc capable d'adresser plus de 4Go. Mais qu'en est-il des programmes ? N'ont-il aucun moyen, sur une plateforme 32bits, d'adresser plus de 4Go ?
Tout depend de ce qu'on appelle un processeur 32 bits. La definition que je prefere est c'est un processeur dont les registres de donnees ont 32 bits.
Avec cette definition, on peut avoir un espace d'adressage de plus de 32 bits (utilise la segmentation avec un OS qui remappe les segments quand c'est necessaire sur un ia32 par exemple et il est courant pour les 8 bits de pouvoir adresser 64K et les 16 bits de pouvoir adresser plus que ca -- 20bits d'adresse pour le 8086 par exemple).
Cette definition correspond assez bien avec l'usage que j'ai vu pour une grande classe de processeurs (y compris des machines adressables par mots avec des mots de 36 bits et un espace d'adressage de 18 bits) mais elle n'est pas reellement universelle.
Les processeurs les plus repandus que j'ai vu designe autrement que je ne le fait sont le 8088 (8bits comme sont bus donnee externe) 68000 (vu qualifie de 16 bits), le 68008 (vu qualifie de 8 bits). Ces deux processeurs sont d'ailleurs amusant de ce point de vue (le 68000 a des registres de 32 bits, un bus d'adresse de 24 bits, a des bus donnee interne et externe de 16 bits, le 68008 a des registres de 32 bits, un bus d'adresse de 20 bits, a des bus donnee interne de 16 bits et externe de 8 bits). Apparememnt la taille du bus de donnee externe est l'autre grand candidats, mais avec les architectures actuelles on aurait donc des processeur 128 ou 256 bits...
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
