Hello
 
Je cherche à expliquer pour mon mémoire la différene entre une architecture 16bits et 32bits au niveau logiciel.
 
A la base, le logiciel que j'ai développé était en Access 2 et Visual Basic 3 (archi 16bits) et a été réécrit en Visual Basic 6 (Archi 32bits).
 
Par contre je ne sais pas expliquer :
- ni ce qu'est une architecture 16 ou 32bits
- ni la différence qu'il y a entre les 2 (différence de fonctionnement, rapidité d'exécution... ?)
 
Si quelqu'un peut m'éclairer ce serait sympa
 
Merci d'avance

guillot a écrit a écrit : Hello   Je cherche à expliquer pour mon mémoire la différene entre une architecture 16bits et 32bits au niveau logiciel.   A la base, le logiciel que j'ai développé était en Access 2 et Visual Basic 3 (archi 16bits) et a été réécrit en Visual Basic 6 (Archi 32bits).   Par contre je ne sais pas expliquer : - ni ce qu'est une architecture 16 ou 32bits - ni la différence qu'il y a entre les 2 (différence de fonctionnement, rapidité d'exécution... ?)   Si quelqu'un peut m'éclairer ce serait sympa   Merci d'avance

 
la difference se situe au niveau de la largeur de bus. 16 bits (2octets) ou 32bits (4octets)
 
au niveau du processeur, il pourra effectuer des calculs sur 32bits plus rapidement (c'est possible de faire du calcul 32bits avec un proc 16bits!)
 
au niveau de ton logiciel, ca change pas grand chose a part l'occupation memoire.
 
ex en c:
un int fait 2octets en 16bits et 4 octets en 32bits
le char ne change pas (1 octet)
 
enfin bref, generalement la seule difference est au niveau du compilo.
 
et une archi 32bits est plus rapide si tu fais des calculs sur des nombres codes en 32bits, sinon c'est pareil (spec des procs mises a part)

Archi 32 bits : mode protégé (chaque processus est "restreint" à son espace mémoire), 4 Go adressables, multitâche
 
Archi 16 bits : 1 Mo adressable, monotâche et bidouillage pour essayer d'obtenir la même chose que le multitache tant que la techno 32 bits était intouchable.

 
en effet mais ca n'a rien a voir avec l'archi mais avec le processeur.
 
et en plus l'adressage memoire n'est pas dependant non plus du 16/32 bits mais de la largeur du bus de donnees (generalement la meme, mais pas forcement)

 
ben si

non non.
Par exemple, un PIII est capable de gérer (et de cacher) 64 Go.
Pourtant, c'est un processeur 32 bits.
 
Je pense que le terme 16 ou 32 bits, c'est uniquement la taille des registres généraux (entiers et adresses) (les EAX, EBX...)

De la même façon, le 8086 gérait la mémoire sur 20 bits avec des registres 16 bits, mais au prix d'un bidouillage de goret

 
Adressables en même temps ?  

J'aimerais que tu m'expliques comment un P3 peut gérer 64 Go.  
 
Ca voudrait dire qu'il adresse sur 36 bits... Si vraiment c'est possible, ça veut dire qu'il lui faut 2 registres 32 bits pour accéder à la zone au delà des 4 Go, et sur les 32 bits du second registre, 28 seront inutilisés.
 
Je pense qu'il doit flipper les pages mémoires, comme au temps des 8 bits qui arrivaient à gérer + de 64 Ko de RAM, mais sur plusieurs pages. Mais bon, jusqu'a preuve du contraire, un P3 n'est pas 36 bits...

 
Oui, d'ailleurs si c'était possible, je me demande pourquoi on passe maintenant à l'archi 64 bits puisque c'est justememnt pour faire péter la limite des 4 Go.

La largeur du bus d'adressage des PII/PIII/celeron est de 36 bits.

Pourtant c'est utilisé:
http://www.microsoft.com/hwdev/pla [...] efault.asp
 
http://tangentsoft.net/ix/pae.html

Dans ce cas, comment y accéder avec uniquement des registres 32 bits ?

Je ne sais pas précisément comment ca fonctionne, mais je sais qu'Intel annonce 64 Go dans les datasheets du PIII, que Microsoft n'hésite pas à dire que 2000 Datacenter peut gérer 32 Go de RAM (sur des PIII), et que Dell ou IBM ont des serveurs avec + de 4 Go, basés sur des processeurs 32 bits.
 
Mais c'est une limite pour le système. Je connais pas toutes les subtilités de l'adressage virtuel en x86, et je ne dit pas qu'un processus seul peut dépasser les 2 ou 4 Go.
Il y a une distinction entre la taille adressable par un processus, et la taille totale utilisable par l'ensemble du système.
 
Le passage à 64 bits devrait permettre de dépasser cette limite par processus.

Y a pas mal de gymnastique d'après les docs des liens.

 
Moi je ne parle que de ça : la taille adressable. En 16 bits on pouvait adresser 1 Mo en même temps, même si, avec l'XMS on pouvait adresser plus mais c'était du bidouillage. Là, le coup des 36 bits, c'est pareil.

 
Par segmentation, comme à l'époque du 8086.
 
R1 et R2 sont des registres 32 bits, PHY est l'addresse physique sur 36 bits.
PHY = (R1 << 4) + R2

Mouais, et en plus je suis pas sur qu'au niveau efficacité du code, ça apporte grand chose... Ca doit être basé sur des décalages de bits à tire larigot.
 
Mieut vaut attendre une vraie architecture 64 bits ! Au passage, ça me fait bien marrer que certaines consoles de jeu estampillent "64 bits" sur leur notice pour ne posséder que 16 ou 32 Mo de RAM... Marketing, quand tu nous tiens !

De toute façon sous windows, pour chaque processus, y a que 2 Go pour l'utilisateur, les  2 autres Go sont pour le noyau (sauf si on mets le switch \3GB dans le boot.ini)

Harkonnen a écrit a écrit :   Mouais, et en plus je suis pas sur qu'au niveau efficacité du code, ça apporte grand chose... Ca doit être basé sur des décalages de bits à tire larigot.   Mieut vaut attendre une vraie architecture 64 bits ! Au passage, ça me fait bien marrer que certaines consoles de jeu estampillent "64 bits" sur leur notice pour ne posséder que 16 ou 32 Mo de RAM... Marketing, quand tu nous tiens !

Ca ne se fait pas dans le processus, ce n'est pas le programme qui calcule lui même les adresses. Lui, il a son espace de taille <= 4 Go, ca tient sur des registres 32 bits, il n'a pas d'opération particulière à effectuer.
 
C'est uniquement lorsque le proc convertit l'adresse logique vers l'adresse physique, qu'il passe à 36 bits.

Si l'on regarde la datasheet d'un P3 (par exemple), le bus d'adresse ne commence pas à A0 mais à A3 (le bus mémoire faisant 64 bits de large, les données sont alignées sur 8 octets).
 
 
Donc tout est décalé de 4 bits, ce qui fait 64 Go d'adressable (ce qui donne bien 4 Gmots de 64 bits).

Harkonnen a écrit a écrit :   Mouais, et en plus je suis pas sur qu'au niveau efficacité du code, ça apporte grand chose... Ca doit être basé sur des décalages de bits à tire larigot.   Mieut vaut attendre une vraie architecture 64 bits ! Au passage, ça me fait bien marrer que certaines consoles de jeu estampillent "64 bits" sur leur notice pour ne posséder que 16 ou 32 Mo de RAM... Marketing, quand tu nous tiens !

 
le fait qu'elles soient 64bits ou non n'est pas pour la taille max de la memoire.
 
il faut bien separer la taille des registres internes de la largeur du bus d'adresse.

ça va ensemble !
si je vois une étiquette "64 bits", je m'attends à avoir en face de moi une architecture 64 bits, et non 32/64 bits.

Tout dépend de ce que tu entends par "architecture 64 bits".
Pour moi, un proc 64 bits est un proc où les registres généraux sont sur 64 bits. Ce sera le cas du Hammer. Mais rien ne dit qu'il sera capable de gérer 2^64 octets de mémoire .

 
 
C'est clair !
 
 
Par exemple les processeurs Sun 64 bit ont un bus d'adresse de 44 bits de large. Et toujours pour des raisons de coût, je serai surpris que le bus d'adresse du hammer fasse 64 bits de large.

pour moi, "architecture 64 bits", signifie qu'un processeur non seulement possède des registres 64 bits, donc permettant de travailler sur des nombres en 64 bits en un seul accès, mais également un bus d'adressage en 64 bits, donc capable d'adresser en théorie 16 777 216 tera-octets !

Y'en a une qui calcule (naturellement) sur 16 bits, et l'autre sur 32.
 
Maintenant, il y a d'autres considérations qui viennent, comme tu peux le voir...
 

100% d'accord.
Jamais compris pourquoi.
 

Ça m'intéresse !
Il faut mettre exactement quoi, sur quelle ligne ?
C'est compatible NT/2000/XP ?
 

16 777 216 giga-octets.
 
A tous
La largeur des registres, du bus de données, du bus d'adresses, du ou des bus internes, du bus électronique effectif, sont en général proches, mais pas forcémment identiques.
Une machine avec des registres n bits:
-Peut adresser n^(2*n) octets avec un registre de segment d'adresse supplémentaire. (segment<<n)+adresse = adresse effective n*2 bits.
-Peut adresser n*x octets en les lisant par blocs de x (Cas du PIII mentionné).
-Peut disposer d'un bus n/2, ou n*2, ou pire/mieux encore.
-Peut généralement faire certains calculs en n*2 bits.
 
Aura-t'on bientôt des int *64 verylongpint; ?