Quelqu'un a un lien qui explique l'adressage sur 36 bits ? Je connaissais pas et j'avoue ne pas trouver.

Wiki est ton ami...
http://fr.wikipedia.org/wiki/Extension_d'adresse_physique

On parle de Windows 64 bits ou de l'adressage 36 bits, là ?

Punaise... je ne connaissais pas cette infâme bidouille... comme dirait Audiard, ça ose tout chez Intel...

Je ne suis pas certain que seule la capacité en bits d'un OS suffit pour savoir s'il peut gérer la mémoire en 32 ou 36 bits. Il m'est avi que certains Gnunux 32 bits voient bien et adressent bien plus de 4 Go de RAM. Qui pour me confirmer?

D'après wikipédia, tu as bon. Il existe certaines magouilles saugrenues pour adresser plus de 4 Go de ram sur un système 32 bits.

Sauf que windows gère la PAE...

Non aucune magouille saugrenue sur un nunux 32 avec plus de 4 Go, juste un kernel PAE suffit.

Par contre sur un Windows je veux bien croire que la manip soit beaucoup plus chiante sur la config de la PAE.

Je pensais à Windows (à cause de la publication) quand j'ai écris mon post. Shame on me.

Ce qui n'empêche pas le fait que Windows limite quand même la quantité de RAM disponible (apparemment cela est dû à des problèmes de drivers de fabricants tiers).

32bit n'est pas la capacité de l'OS. C'est juste la taille des pointeurs mémoires.

La PAE (Physical Address Extention), d'après wikipedia passe l'adressage complet de 32bit à 36bits. Passant donc de 4Go à 64Go. (2^36 -1)

Mais l'architecture reste en 32bit (taille des registres). Du coup aucune application n'arrive à prendre plus de 4Go. Seul le noyau voit les 36bits et si je ne m'abuse les stocke dans le contexte de l'application.

Windows non serveur ne supporte que 4Go en édition 32bits. [1]
Je ne vois que deux explication
- Pas de PAE
- PAE mais limité par un truc dans la licence.

Dans les deux cas c'est la merde.


[1] http://msdn.microsoft.com/en-us/library/aa366778.aspx#physical_memory_[...]

Je voit pas en quoi le PAE est une "infame bidouille".

Primo, il a été introduit en 1995 sur les pentium pro, bien avant le x86-64, c'était donc le seul moyen de dépasser les 3go de ram pendant presque 10 ans, bien que cela concernait uniquement les très gros serveurs.

Secundo, le projet d'intel à la fin des années 90 était l'abandon à terme de l'architecture x86 et son remplacement par l'IA-64 utilisée sur l'itanium. Dans ce contexte, le PAE avait tout son intérêt tant que la transition n'était pas complète.

Ensuite, la transition x86 vers x86-64 aurait été moins problématique si Microsoft ne limitait pas artificiellement la ram gérée par les windows grand public.

Sinon, rien à voir, mais ça ne devrait pas être le jour du PROZAC, aujourd'hui ?

Du coup BEDP ?

Avec PAE peut-on envisager que chaque appli ait pour elle seule 4 Go je veux dire appli_1 4 Go et appli_2 4 Go donc les deux exploitent les 8 Go?

Vous sentiriez-vous aussi fatigué de cette accumulation de PEBKAK?

Soit ça, soit les_joies_du_code(); subit réellement un détournement de gifs.

Le PAE est géré par Windows, et sa mise en place est assez simple. Il suffit d'éditer le boot.ini et d'ajouter un paramètre à la ligne de démarrage de Windows

@Digi : exactement. Mais ton jeu favori ne pourra pas aller au delà.

ou bcdedit /set pae forceenable pour les versions > 2003/XP

Du coup, quelqu'un pour m'expliquer l'avalanche de votes CTLP ? Le PEBKAC, c'était pour moi c'est celui qui disait « Et oui, pas le choix, puisque le système change complètement son architecture lorsque l'on passe de 32 à 36 bits » alors que le problème est posé en terme de migration 32==>64 bits, et que l'utilisation de PAE, pour autant qu'elle puisse être possible, n'est pas envisagée par défaut sur les windows 32 bits non serveur. Peut-être aurais-je dû vérifier qu'il y avait un moyen de l'activer, mais c'est un sujet qui ne m'a jamais concerné. Dès que j'installe un windows sur une machine à plus de 2Go, j'installe du 64b.

Il n'y a pas vraiment de problème technique à avoir un adressage de taille différente de celle du bus de données. Le 8086 de 1978 avait des registres et un bus de données de 16 bits et un adressage de 20 bits. Ce n'est pas un bidouillage à proprement parler et ça n'a rien d'infâme. La bidouille si situe plutôt au niveau du système d'exploitation qui gère ça de manière peu transparente.

Attention, que l'on parle de 32 ou de 64 bits, il ne s'agit absolument pas de la taille des pointeurs mémoire mais de la taille des registres et du bus de données. Pour un core i7 ou un phenom, par exemple, l'adressage se fait sur 40 bits.

lapincompris, kissikoné et leurs amis sont venus voter. Sinon oui possiblement la bourde sur Windows qui ne supporte pas la PAE, peut-être aussi un style narratif qui déplait. Ah oui et puis quand on va lire 3 pages de doc sur le sujet que tu nous fais découvrir, il y a aussi le risque d'oublier de revenir plussoyer le pebkac ;)

Le CTLP, c'est pour avoir ajouté "ce n'est pas pris en charge par windows". Comme on le dit souvent, le trop est l'ennemi du bien...

EN fait la seule erreur (pas bien grave en soi) dans ce que dit l'utilisateur est les 36 bits correspondent effectivement à l'adressage mémoire en X86-32 avec PAE, et non au X86-64 qui est de 48 bits.


Ensuite, tout les windows y compris les versions "grand public" (depuis win 2000) gérent le PAE, mais son utilité est limitée vu que la plupart des versions vont de toute manière limiter plus ou moins la ram utilisable, sans lien avec l'architecture matérielle. Par contre, il faut activer le pae pour pouvoir utiliser le NXbit et autres fonctionnalités.

Enfin, pour la question du changement majeur entre x86-32 et x86-64 il n'a pas tord. Même le passage de 32 à 36 bits du PAE implique un certain nombre de changement dans l'architecture que l'os et les pilotes doivent pouvoir gerer.

Linus Torvalds lui-même n'aime pas le PAE, et si on l'active par défaut cela fait des kernel panic sur les CPU non compatibles (par exemple un Geode qui est en i586).
j'imagine qu'en 2014 il vaut mieux forcer le passage en 64 bits, qui existe commercialement depuis 11 ans, que d'encourager des bidouilles comme le PAE.
Celui qui a besoin de plus de 4GB de ram a tout intérêt à être en 64 bits...

@Anomine houlà il ne faut pas confondre architecture x86-64 de ce qui est réellement implémenté pour cette architecture.

Certes le I7 ne sait gérer que 48bit en virtuel qui transforme en adressage de 40bit.
Mais l'instruction prend bien 64bit et il y a 17bit qui doivent être identique.[1,2,3]
Lorsque tu fait un chargement "MOV" [3] t'as bien un pointeur de 64bit qui n'est pas dans la version 32bit [4].

Par contre le bus de données du I7 est de 128bits [5]
Le bus de donné de la DDR3 est de 64bit ainsi que la DDR2 que l'on utilisait avec des processeur 32bit.

Pour le système d'exploitation le pointeur fait bien 64bits.
Pour ceux qui veulent essayer :

#include <stdio.h>
 
 int main(){
   printf("%ld bits/n",sizeof(int)8);
   return 0;
 }

Ce programme répond.
"64 bits" sur un linux en 64bits
"32 bits" sur un linux en 32bits
[1]http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details
[2]http://www.linuxquestions.org/questions/linux-hardware-18/address-size[...]
[3]http://ref.x86asm.net/coder64.html
[4]http://ref.x86asm.net/coder32.html
[5]http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.[...]

@Anomine houlà il ne faut pas confondre architecture x86-64 de ce qui est réellement implémenté pour cette architecture.

Certes le I7 ne sait gérer que 48bit en virtuel qui transforme en adressage de 40bit.
Mais l'instruction prend bien 64bit et il y a 17bit qui doivent être identique.[1,2,3]
Lorsque tu fait un chargement "MOV" [3] t'as bien un pointeur de 64bit qui n'est pas dans la version 32bit [4].

Par contre le bus de données du I7 est de 128bits [5]
Le bus de donné de la DDR3 est de 64bit ainsi que la DDR2 que l'on utilisait avec des processeur 32bit.

Pour le système d'exploitation le pointeur fait bien 64bits.
Pour ceux qui veulent essayer :

#include <stdio.h>
 
 int main(){
   printf("%ld bits/n",sizeof(int)8);
   return 0;
 }

Ce programme répond.
"64 bits" sur un linux en 64bits
"32 bits" sur un linux en 32bits

Désolé les lien références ne passent pas. Mon post disparaît.
@clem : pourquoi ? Quand j'édite pour les ajouter.

1. en.wikipedia.org / wiki / X86-64#Virtual_address_space_details
2. www.linuxquestions.org / questions / linux-hardware-18 / address-sizes-in-cpuinfo-757456
3. ref.x86asm.net / coder64.html
4. ref.x86asm.net / coder32.html
5. upload.wikimedia.org / wikipedia / commons / 6 / 64 / Intel_Nehalem_arch.svg

Voilà le post complet.
http://pastebin.com/tvfvkVLD

Oui tu as raison sur tous ces points mais encore une fois, la désignation 32 ou 64 bits pour l'os ne se réfère pas à la taille des pointeurs mémoire. Le fait qu'il s'agisse de pointeurs de 64 bits, c'est juste pour qu'ils soient «assez grands» par rapport aux capacités physiques du processeur. Mon explication était un peu bancale et trop courte mais c'était ça l'idée.

Arrête moi si je me trompe.

Pour moi 32 ou 64bit pour l'os est un abus de langage qui se réfère à l'architecture pour laquelle il a été compilé. soit X86 ou X86-64.

En réalité la différence entre ses deux jeux d'instructions c'est la possibilité d'utiliser un nombre de 64 dans les instructions mémoires,
Par exemple "Move /64b Rax" et du coup ajouter des bits dans les registres nécessaire à l'exécution comme Rax,Rbx, (histoire de pouvoir manipuler le chargement indirecte efficacement) R8-15 etc.

Le truc rigolo c'est que c'était déjà le cas dans certain CPU pour optimiser certaines instructions.
Comme on le voit dans le i7 les registres sont en fait en 128bit et il peut exécuter plusieurs instructions en un cycle. Il y a un volume entier de documentation sur le site d'intel qui explique tout cela.

Tout cela pour dire qu'il y a une différence entre les caractéristiques physique du processeur et la norme dans lequel in s'inscrit.
Et que ça réfère bien à cette limitation d'adressage car on est arrivé au max de l'espace virtuel sur 32bit.

Historiquement la désignation 16/32 bit se réfère à la taille de l'entier standard utilisé. Elle se réfèrait donc à la taille des registres et jamais à la taille de l'espace adressable. Pour la différence entre 32 et 64 bit, c'est l'utilisation des instructions x86-64 qui fait la différence mais encore une fois ça ne se réfère pas à l'espace mémoire adressable qui n'est qu'une conséquence de l'utilisation de x86-64.

Ce qui me gène avec cette définition c'est que l'entier standard n'a aucun sens coté hardware.
Sur un Linux 64bit le int qui est toujours l'entier standard n'a que 32bits comme pour les distrib 32bits.

La taille d'un registre est de 128bits hardware pour le nehalem et avec certaines instructions spéciales intel. Il monte à 512bit si mes souvenir sont bon.
Car il peut faire plusieurs instruction en un cycle. Donc le fait qu'il gère que 40bit sur la mmu on s'en fout en fait.

Mais effectivement j'ai des pic où il faut charger l'adresse mémoire en deux instruction (changement de page)

Pour moi ça n'a pas de sens de l'extraire du nom de l'archi même historiquement.
Sauf qu'en plus historiquement c'était la taille des accumulateurs. C'est à dire ou le coeur prend ces données et les recraches ou même le mot manipulable par le CPU. Pas forcément les registres qui étaient souvent plus gros.
ex 68hc11 microcontroleur de 8bit a tout ses registres en 16bits. Seul l'accumulateur A et B sont de 8bit tout deux formant le registre D et un bus de données de 8 et d'adressage de 8 également.
Son voisin 68hc16 (16bits) a la même chose mais les deux accumulateur et les bus sont en 16bits. Quelques registres passent en 20.


Même là ça ne s'applique pas... (128bit pour l'i7 - on doit par contre faire deux instruc pour le charger de la ram. Mais pas de la mem cache !)
Je comprends pourquoi seul le compilateur d'intel a de bonne perf ;)

"Pour la différence entre 32 et 64 bit, c'est l'utilisation des instructions x86-64 qui fait la différence"
On est d'accord, on se fout de comment elles sont exécuté.

Mais du coup c'est quoi la différence entre les deux et qu'est ce qui a motivé le passage ?
C'est à dire qu'est ce que le précédent jeu d'instruction ne permettait-il pas de faire ? (sans tricher avec la mmu)

ps: je me suis peut-être ma exprimé avant ou maintenant.

Non mais même si tu mets le flag PAE sous windows 32bit non serveur t'es quand même limité à 4Go

En fait, techniquement, tu t'y connaît beaucoup mieux que moi, il y a juste une chose ou tu te trompes, c'est que tu considères que c'est l'utilisation de pointeur mémoire de 64 bit qui est à l'origine du terme alors qu'il s'agit de la conséquence de l'utilisation de l'architecture x86-64. Bien entendu, le fait de pouvoir utiliser une plus grande quantité de mémoire était un des arguments majeurs pour passer à une nouvelle architecture, pas la seule cependant, mais il n'en reste pas moins que l'accès à plus de mémoire est une conséquence de la nouvelle architecture.

En me relisant, je me dis que c'est pas clair, ce que je raconte.
Je vais essayer autrement.
Tu considères que le nom vient de la taille des pointeurs mémoire et que l'architecture alors que le nom vient de l'optimisation (un bien grand mot) pour les architectures x86-64. Que les pointeurs aient cette taille est le résultat d'un choix concernant celle ci et il est possible que le nom de l'architecture soit influencé par ça mais il y a dans ta démonstration un lien de transitivité qui n'est pas évident. Autrement dit, le gars qui a donné le nom à l'os, il l'a fait parce qu'il est conçu pour x86-64 et le gars qui a donné son nom à x86-64 l'a peut être fait à cause de la taille des pointeurs mais l'un n'implique pas l'autre. C'est un peu comme si tu disais que c'est parce ma voiture peut rouler à 200 km/h que j'ai eu un accident en roulant à 160. J'ai pu rouler à 160 parce que ma voiture le permet mais ce n'est pas la cause de l'accident. Le raisonnement n'est pas tout à fait le même mais c'est quelque chose du même ordre.

@Anomine : comme je disais le nom pour l'OS vient directement du jeu d'instruction sur lequel il a été compilé.
Le fait de pouvoir utiliser plus de 4Go en est une conséquence. Je suis d'accord.

Mais j'ai du mal à saisir les réelles différences entre les deux archi à part cette conséquence.

Ce n'est pas un concours de celui qui a la plus grosse. Je pense que tu as un autre regard sur la chose.
Je pensais qu'en résumant mon raisonnement tu pouvais pointé du doigt ce qui n'allait pas et être enrichissant.

Puis j'ai aussi du mal à voir quel élément d'un core i7 montre que c'est un processeur 64bits juste en regardant le hardware. Sur les vieux coucou c'était assez clair, mais maintenant ...

ps : le X86-64 arriva dans le PIV prescott d'après mes souvenir. Sauf que l'architecture netburst qui équipe tout les PIV sont vachement ressemblant entre le différents PIV. (contrairement à l'archi P6 du pentium III)
Même avec Core ce n'est pas super différent de netburst.

http://www.info.univ-angers.fr/pub/richer/ensl3i_crs5.php

En fait, je suis un peu comme toi, à part augmenter la taille de la mémoire, j'ai du mal à voir la différence entre les deux mais le raccourci que tu fais me gêne car il va dans deux sens opposés à la fois. Bref, c'est juste du vocabulaire et je crois que c'est une discussion qui pourrait durer encore très longtemps mais en fait on est d'accord sur le fond !

en ce qui me concerne, le CTLP, je te l'adresse comme à beaucoup pour avoir traité de "PEBKAC" ce qui est une simple erreur, sur un sujet très pointu. Tu ne parles pas d'un mec crétin ou niais, juste d'un mec qui se trompe.
Si commettre une erreur sur un sujet technique pointu c'est être un PEBKAC, alors tous les informaticiens doivent l'être, et souvent plusieurs fois par jour.

On vient sur ce site pour lire des récits de personnes débiles, arrogantes, incohérentes ou fainéantes, parce que ça nous fait rire. Je ne vois vraiment pas ce qu'il y a de drôle dans ton histoire. Si c'est juste pour nous montrer que tu t'y connaissais plus que ce mec sur le forum, super pour toi mais moi je m'en tape.

En fait, puisque l'argument est bon, on se demande simplement si le supposé PEBKAC ne s'est pas trompé (un lapsus ?) en tapant 36 au lieu de 64.

En tout cas, le fait que :
1) il a raison et 2) la PAE est prise en charge par Windows (même si la version XP 64 est basée sur 2003)

fait qu'on a tendance à penser CTLP

Tiens les posts on fini par arrivé et merde -_-"

Sur un forum, un mec répond à un problème technique à côté de la plaque en s'aventurant dans un propos n'ayant pas de rapport avec le sujet. PEBKAC Quand à la faute de frappe pour arriver de 64 à 36, il faudrait taper avec des moufles, qu'on aie ou non un pavé numérique...

"Mon gars"