Architecture processeur (8,16,32,64 bits)

[Alexandreg12]

Si j'ai bien compris, un processeur 8 bits est capable d'effectuer des opérations sur des nombres de 8 bits (16bits, nombres de 16 bits - 32 . . . on comprend la suite)

Je me demande, si on prend par exemple une variable double en c, cette valeur utilise 64 bits de mémoire . . .

Comment un processeur 32 bits fait pour effectuer des opérations avec un nombre si gros?

Merci d'essayer de me faire comprendre tout ça

Alex

[milouz123]

En mémoire, on peut stocker des nombres de taille très très grande, bien plus grande que celle d'un registre. On pourrait très bien avoir un nombre de 1024 bits par exemple ! Grosso modo, en admettant que l'on travaille sur des registres de 8 bits, il faudra beaucoup d'opérations pour faire un calcul sur de tels nombres.

[wiztricks]

Il ne faut pas confondre l'espace adressable (16 bits, 32 bits, 64bits) et la "taille" des données sur lesquelles le CPU va faire une opération: 8, 16, 32, 64, ... bits.
=> un processeur peut avoir un espace d'adressage 32 bits et "savoir" faire l'addition d'entiers représentés par des champs de longueur 16 ou 64 bits.
Cela est limité par la taille des registres du CPU.

Note: ce qui n'interdit pas l'écriture de programmes pouvant travailler sur des nombre plus grands, mais nous ne parlons plus de capacités d'un CPU dans ce cas.

- W

[Obsidian]

Envoyé par Alexandreg12

Je me demande, si on prend par exemple une variable double en c, cette valeur utilise 64 bits de mémoire . . . Comment un processeur 32 bits fait pour effectuer des opérations avec un nombre si gros?

Il procède en plusieurs fois.
Tu fais parfois de même :

Quand tu fais une division sur papier, tu peux traiter un nombre d'une longueur arbitraire en prenant les chiffres les plus à gauche, en les réduisant au minimum, puis en faisant descendre le chiffre suivant, et ce jusqu'à ce qu'il n'en reste plus.

Tu travailles donc au niveau du chiffre, et tu itères ton algorithme.

Ton processeur va procéder exactement de la même façon, soit par câblage, soit avec un programme, en utilisant des mots de taille fixe, par exemple 8 bits ou 32 bits.

[Jean-Marc.Bourguet]

Envoyé par Alexandreg12

Si j'ai bien compris, un processeur 8 bits est capable d'effectuer des opérations sur des nombres de 8 bits (16bits, nombres de 16 bits - 32 . . . on comprend la suite)

Non. Un processeur N bits a des registres d'usage général de N bits (du moins c'est la définition classique, il y a eu des cas où le marketting en a décidé autrement, dans les deux sens, mais ils sont relativement rares). Il peut en avoir d'autres tailles, plus petits ou plus grand. Les processeurs 8 bits que j'ai programmé avaient tous des instructions capables de manipuler des quantités sur 16 bits, stockés soit dans des paires de registres, soit dans des registres spéciaux.

Ce nombre de bits n'a pas de rapport fixe avec la largeur des circuits internes faisant les calculs -- à supposer pour commencer que ces circuits aient tous la même largeur. Dans certains cas, les circuits sont plus larges parce qu'aussi utilisé pour d'autres choses, dans d'autres ils sont plus étroits; dans ce dernier cas, les opérations sont faites en plusieurs temps.

Je me demande, si on prend par exemple une variable double en c, cette valeur utilise 64 bits de mémoire . . .

Comment un processeur 32 bits fait pour effectuer des opérations avec un nombre si gros?

Les processeurs capables de manipuler des flottants ont généralement des registres dédiés d'une largeur correspondantes et des circuits dédiés aussi. Vu la complexité des opérations, elles se font quand même en plusieurs temps.

Envoyé par wiztricks

Il ne faut pas confondre l'espace adressable (16 bits, 32 bits, 64bits) et la "taille" des données sur lesquelles le CPU va faire une opération: 8, 16, 32, 64, ... bits.
=> un processeur peut avoir un espace d'adressage 32 bits et "savoir" faire l'addition d'entiers représentés par des champs de longueur 16 ou 64 bits.
Cela est limité par la taille des registres du CPU.

Effectivement, il ne faut pas confondre. L'espace d'adressage n'a vraiment que peu de rapport avec la taille des registres d'usage généraux. Les processeurs 8 bits avaient généralement un espace d'adressage sur 16 bits. Il y a eu des processeurs 16 bits avec 20 bits d'adressages. Des processeurs 32 bits avec des registres d'adresse de 32 bits également dont seulement 20 servaient à bâtir les adresses. Les derniers processeurs 32 bits d'Intel et AMD étaient capables d'adresser plus que 32 bits. En fait, ne pas prévoir assez de bits d'adresse est l'erreur la plus fréquente dans les architectures et toutes se sont retrouvées limitées par cela et ont eu recours à des trucs plus ou moins gracieux pour s'étendre.

[Obsidian]

Envoyé par Jean-Marc.Bourguet

Effectivement, il ne faut pas confondre. L'espace d'adressage n'a vraiment que peu de rapport avec la taille des registres d'usage généraux.

Ce n'est pas tout-à-fait vrai. Les ambigüités viennent surtout du fait qu'il n'y a pas de définition claire de la n-arité de l'architecture d'un processeur. Pour moi, on peut étiqueter un CPU de façon assez fiable au vu de deux choses :

- la taille de son ALU ;
- la largeur de son bus de données.

Les processeurs 8 bits avaient généralement un espace d'adressage sur 16 bits. Il y a eu des processeurs 16 bits avec 20 bits d'adressages. Des processeurs 32 bits avec des registres d'adresse de 32 bits également dont seulement 20 servaient à bâtir les adresses ...

Oui, mais il ne faut pas oublier les choses plus exotiques comme certains microcontrôleurs qui disposent de 256 octets (oui, oui) de RAM intégrée ou les hybrides tels que le Saturn des HP48, microprocesseur 4 bits dédié au calcul dont les registres en faisaient cependant 64 (déjà, à l'époque).

En fait, ne pas prévoir assez de bits d'adresse est l'erreur la plus fréquente dans les architectures et toutes se sont retrouvées limitées par cela et ont eu recours à des trucs plus ou moins gracieux pour s'étendre.

C'est-à-dire que ce n'était pas forcément facile de faire grand à l'époque, ni surtout très utile. Au bout d'un moment, les limites sont toujours atteintes. On se souvient tous du « 640K should be enough for everyone » et c'était vrai à l'époque !

D'autre part, les segments du mode réel des processeurs Intel 8088 et 80x86, qui ont causé autant de tracas aux débutants que les pointeurs du C, s'expliquent aussi de cette manière, il était beaucoup plus facile de faire deux registres de 16 bits (dont un existait déjà) plutôt qu'un grand registre de 20 bits. Non seulement il aurait fallu prévoir un bus interne spécial pour le charger, mais en plus cela aurait brisé la compatibilité ascendante. En outre, le décalage de 4 bits du registre de segment par rapport à celui d'offset permettait de rendre immédiatement relogeables les programmes qui ne l'étaient pas, avec une granularité de 16 octets.

[Alexandreg12]

J'ai trouvé le livre "How Computers Work" de Roger Young (Il offre une copie en-ligne gratuite) qui part vraiment de la base complète. Je crois que je vais en apprendre beaucoup! C'est une bonne lecture avant de dormir

[Jean-Marc.Bourguet]

Envoyé par Obsidian

Ce n'est pas tout-à-fait vrai. Les ambigüités viennent surtout du fait qu'il n'y a pas de définition claire de la n-arité de l'architecture d'un processeur.

Si, la defition que j'ai donnee; elle fait le consensus des gens s'occupant d'architecture des ordinateurs et decrit bien l'usage passe (voir par exemple le message de John Mashey sur ce sujet sur comp.arch), meme si elle ne le decrit pas toujours totalement. Le probleme est qu'elle n'est pas toujours employee, pour des raisons qui tiennent au marketting, soit pour faire paraitre le processeur comme plus puissant (cas des consoles 128 bits), soit au contraire pour donner l'impression d'un processeur plus petit (cas du 68008 qui a ete qualifie de 8 bits).

Pour moi, on peut étiqueter un CPU de façon assez fiable au vu de deux choses :

- la taille de son ALU ;
- la largeur de son bus de données.

Ce ne sont pas des caracteristiques de l'implementation, pas de l'architecture (pour employer la nomenclature de Brooks, ou de l'architecture, pas de l'ISA pour employer la nomenclature de Hennesey et Patterson). Hors l'usage est relativement universel a considerer les caracteristiques architecturales, le probleme des caracteristiques de l'implementation est que deux implementations differentes de la meme architecture peuvent avoir fait des choix differents.

Dans le cas de l'ALU, il peut y en avoir plusieurs de largeur differente, etre plus large que necessaire pour les registres d'usage general, parce que reutilisee pour autre chose (par exemple pour le calcul d'adresse), ou etre de largeur inferieur et les operations effectuees sequentiellement.

Dans le cas du bus de donnees, il peut etre multiplexe avec le bus d'adresse plus large, il peut etre plus petit que les registres d'usage generaux et les lectures se font en plusieurs temps, il peut etre plus grand parce qu'il est utilise pour remplir des caches et qu'il a la largeur d'une ligne de cache.

Oui, mais il ne faut pas oublier les choses plus exotiques comme certains microcontrôleurs qui disposent de 256 octets (oui, oui) de RAM intégrée

Je connais... j'ai ecrits quelques programmes pour ce genre de betes.

ou les hybrides tels que le Saturn des HP48, microprocesseur 4 bits dédié au calcul dont les registres en faisaient cependant 64 (déjà, à l'époque).

Je connais pas ce processeur la. C'est certain que c'est dans les machins exotiques qu'on a le plus de chance de trouver quelque chose ou la definition ne s'applique pas, ou de vouloir utiliser autre chose parce qu'on veut mettre en evidence une autre caracteristique.

C'est-à-dire que ce n'était pas forcément facile de faire grand à l'époque, ni surtout très utile. Au bout d'un moment, les limites sont toujours atteintes. On se souvient tous du « 640K should be enough for everyone » et c'était vrai à l'époque !

Non, on savait deja que ce serait insuffisant, le probleme avait deja ete vecu plusieurs fois. L'histoire en architecture se repete toujours au moins trois fois, une fois pour les mainframes, une fois pour les minis, une fois pour les micros. Mais la question est plutot est-ce qu'on avait le choix, prevoir cela pouvait etre trop couteux.

... x86 et ses segments...

Il faut en plus tenir compte du fait que le 8086, c'etait une solution d'attente pour le (je ne sais plus quoi qui jusqu'a l'Itanium etait le plus bel echec d'Intel).

[ALT]

En matière d'échec, il y en eut un somptueux : le 80186 !
Car les PC sont passés du 8086 au 80286 sans transition.
Faut dire que le 80186 n'apportait pas beaucoup de nouveautés par rapport au 8086.

[Jean-Marc.Bourguet]

Envoyé par ALT

En matière d'échec, il y en eut un somptueux : le 80186!

Il a eu une assez belle carriere dans l'embarque, ce qui etait sa cible. Pas un echec cuisant comme l'Itanium ou l'IAPX 432 (si je me souviens bien de la denomination).

[ALT]

Ahum !
Bon, après vérification :
Le 80186 est arrivé après le 80286 (là, j'ai eu tout faux précédemment). En fait, il contenait plus d'instructions.
Mais je maintiens qu'il a eu peu de succès.
Sauf à admettre que sa seule destination était l'embarqué.
Ce que mes sources ne précisent pas (Les Microprocesseurs, Dunod, 1995).