La saga Cyrix : un 386 sous le nom 486

Petit dossier sympa (comme les précèdent) à noter un problème de mise en page à la page 11 (partit droite tronquée).

le 486 dx4 100 mhz mais a cycle d'horloge pour les envoie de donner si je me rappelle bien donc 15mhz de fréquence effective

J'ai rien compris, mais la fréquence était bien de 100 MHz, avec un FSB généralement à 33 MHz, donc un rapport bien moins élevé que maintenant.

Crusoe est 128 bits et efficeon 256bits, vous vous trompez.

pas en mode x86.

j'ai encore 3 6*86mx qui dorme au placard

3 ? Wow, j'ai qu'un seul 6x86 en stock

Sinon, revoir tout ces noms, ca fait bizarre, à désespérer des duopoles ATI/NVIDIA et AMD/Intel.

J'ai gardé un 6x86 P150+ (à 120 MHz, "overclocké" à 133 MHz) un petit moment (il a succédé à un P75 "vitaminé" sur ma Shuttle 430TX) - jusqu'à ce que, tombé sur un P133 d'occase avec un (pour l'époque) gros ventirad, je ne monte celui-ci à 166 MHz (2x83 MHz, toujours sur la TX). Ben, un P133@166 MHz avec 64 Mo de SDRAM et 512 Ko de cache pipeline burst tournant à la moitié de la fréquence d'horloge CPU sur un chipset 430TX, à côté le 6x86 (et ses multiples patches pour tel ou tel jeu, et l'instabilité chronique de Windows 95 OSR 2 avec, et le boucan abominable de son ventirad bouillant), il tenait pas la rampe. En fait, le seul système de cette catégorie (586, entre 100 et 200 MHz) qui lui ait flanqué une ratatouille était un P166 MMX underclocké à 150 MHz - mais avec un chipset Via, de la SDRAM et un FSB à 100 MHz, le cache de 512 Ko tournant aux 2/3 de la fréquence CPU rendait cette puce plutôt agile.
A côté, le matos Cyrix et ses grillades sauvages, les puces Rise et leur absence remarquée du marché des pièces détachées etc. ont fait qu'il n'y avait que deux fabricants de puces valables: Intel et AMD.

Les puces Cyrix avait moins de errata que les puces Intel et AMD d'un autre coté
Principalement, les incompatibilités étaient le fait de programmation "un peu limite"
http://membres.multimania.fr/jpzanier/M2/incompat.htm

Ensuite, si je me rappel bien, les cpu intel ne respectaient pas pleinement au moins une norme pour la FPU. Les softs étant adapté pour fonctionner avec ce "bug volontaire", la puce Cyrix qui respectaient les normes, évidemment, ne fonctionnaient pas avec ces softs.

Bref, mis à part une puce qui chauffait à mort, j'ai eu une excellente expérience avec Cyrix.

@glitter: il n'y a pas de 'norme' x86, mais seulement une spécification, rédigée par Intel (et maintenant, AMD, pour la partie 64-bit): le court errata du Cyrix était une bonne chose pour quelqu'un qui programmait d'après la doc officielle, mais signifiait aussi qu'un programme pour Cyrix ne tournait que sur Cyrix... Et signifiait aussi que quiconque écrivait un logiciel qui plantait sur un Cyrix ne savait pas programmer.

Marrant de constater, d'ailleurs, que le plus gros (et célèbre) plantage sur Cyrix était sous Windows 95 OSR 2, suite à une boucle mal programmée par Crosoft.

Je n'ai pas gardé un si mauvais souvenir que cela du Cyrix, si ce n'est que:
- les jeux 3D sous DOS ne tournaient pas plus vite qu'avec le P75 qu'il remplaçait, ce qui était un peu gênant
- je devais régulièrement tapoter le ventilo pour qu'il arrête de vibrer
- il chauffait tellement que je devais jouer boîtier ouvert non pas pour le rafraîchir, mais pour éviter qu'il me brunisse mes nappes IDE
La puce elle-même aurait été correctement refroidie, j'aurais probablement gardé mes sous plutôt que de prendre le P133.

Etant moi même collectionneur d'anciens CPUs je trouve cette article plutôt complet.
Apparemment Fujitsu avait une licence Intel pour ses Pentiums mobiles :

http://deuttai.homeip.net/cpu/?go=show&m=14&f=512

Oh que si.
http://en.wikipedia.org/wiki/IEEE_754-2008

Quand aaux vieux soucis sur les FPU Intel et AMD, j'ai retrouvé ca par exemple
http://www.tybor.com/



Je parlais des errata dans le sens que la puce Cyrix, à priori, devait être fiable, et on a vu ce que ca a donné.



Effectivement, cette histoire de fpu légère est décevante.
J'avoue que ca m'a toujours étonné d'ailleurs de voir Cyrix et AMD si à la rue à l'époque.
D'aprs ce que j'avais trouvé sur le net, avec le pentium, Intel avait une fpu qui était une vraie révolution dans la gamme x86 ... mais qui aavit un bug facheux.
1) Les brevets déposé par Intel ont empéchés les concurrents de faire un modèle approchant et ont dus attendre d'avoir leurs propres solutions. AMD a pus avoir les ingénieurs de chez Alpha, Cyrix n'a pas eu d'opportunité de ce genre.
2) Certains ingénieurs séniors ont été virés, notamment ceux qui avaient concus la fpu .... ce qui fait toutefois qu'Intel a stagné de nombreuses années et a permis un retour en force d'AMD avec le K7.

Pour en revenir à cyrix, rapidement le 6x86 a montré sa faiblesse au niveau:
De la FPU
De la vitesse en Mhz.
Poru ce dernier cas, c'est facile à expliquer, STM n'avait pas une technologie de fabrication excellente et IBM ne produisait pas les puces dans ses usines les plus performantes. Le passage chez National Semiconductors passant de 0.35 à 0.25 n'arrange en rien les choses.
http://www.pctechguide.com/24Cyrix_6x86MX.htm
By the summer of 1998 0.25-micron MII-300 and MII-333 processors were being produced out of National Semiconductor's new manufacturing facility; in Maine and the company claimed to have already seen shrinks of its 0.25-micron process to produce 0.22-micron geometries on its way to its stated goal of 0.18 micron the following year.
Il faut lire évidemment le passage comme "le 0.25µ est tellement pourri qu'on tente de le faire évoluer vers le 0.18µ".
IBM avait tenté de garder une production pourtant, et un site avait pus tester un modèle ES en 0.30µ et il y avait un bond en Mhz assez important malheureusement, on sait ce qu'il est advenue, et surtout qu'avec NS, le seul produit qui importait était le Media GX.
Les projets de super 6x86, Jedi/Gobi/ Cayenne ayant été repoussés puis abandonnés.
En fait, il semble que la firme n'avait pas le poids critique pour continuer la course avec ses concurrents, le modèle économique n'étant franchement pas terrible.

[...]

Heu, attends, là: la norme que tu références concerne la FPU, pas le jeu d'instruction x86: pour être même hyper précis, IEEE 754-1985 (prédécesseur de l'IEEE 754-2008) a eu pour première implémentation complète et juste l'Intel 8087 (basé sur le brouillon - draft - de la norme), duquel sont descendus tous les coprocesseurs suivants et la FPU des 486DX et puces suivantes ('487'). Donc non, le jeu d'instructions et l'assembleur x86 ne sont pas normalisés: ils sont couverts par une spécification constructeur, et cette spécification a été rédigée par Intel jusqu'au Pentium Pro (les instructions SSE et MMX ont une spécification différente, voir le procès Intel-AMD sur le support MMX dans le K6) puis avec AMD pour les extensions 64-bit.

Après, tous les processeurs 'compatibles x86' implémentent cette spécification; l'errata d'une génération de processeur intègre entre autres:
- les déviations constantes par rapport à la spécification
- les cas particuliers où le processeur peut dévier par rapport à la spécification (pas de déviation en opération normale)
Un errata est souvent augmenté a posteriori: il est fort possible que l'errata du Cyrix soit petit parce que personne n'a ajouté d'erreurs (des développeurs qui ont fait du forcing avec un Cyrix, y'en avait quand même pas beaucoup), ce processeur n'ayant jamais été utilisé sur des machines 'pro' (au contraire des processeurs Intel et AMD) avec des processus de validation beaucoup plus longs.

Si l'on considère l'implémentation de référence (le Pentium) des spécifications 80586/80587, le Cyrix:
- nécessitait plusieurs passes pour effectuer un calcul FPU là où le Pentium n'en nécessitait qu'une,
- nécessitait beaucoup moins de cycles pour certaines boucles que le Pentium.

Là où AMD avait fait très fort dans le K7, c'était en recréant une implémentation complètement différente de la norme IEEE 754-1985, plus performante que la version d'Intel (grâce, comme tu dis, aux anciens de chez DEC et Intel embauchés par AMD) surtout sur les calculs à double précision, ce qui leur a permis de 'gommer' le dernier défaut du K6 (fortement basé sur les processeurs de NexGen): sa FPU, un 487 gonflé.

Je n'ais jamais parlé du X86.



Wow, tu me fait peur, car le 6x86 avec "peu" d'errata, c'était un peu moins d'une cinquantaine à sa sortie, j'ose pas imaginer les autres procs avec 3 ans ...

Moi j'parlais de la norme x86, juré! C'est pourquoi ta réponse me semblait bizarre. M'enfin bon.

Ensuite, on va prendre le cas du Intel Pentium d'origine, avec son splendide bogue de FPU (le P5, hein, pas le P54C) découvert en 1994, et le bogue f00f; ces deux bogues ont été corrigées dans la révision suivante, le P54C.

Plus récent, une bogue AMD sur des Opteron 2.6 et 2.8 GHz avec un mauvais ordre d'exécution sur une opération FPU exécutée des millions de fois en boucle: en utilisation normale ou même intensive, la bogue n'apparaît pas; c'est seulement dans le cas où on pousse vraiment le proc' qu'il déconne. AMD a mis deux ans à déterminer qu'il y avait un problème, parce que celui-là tombe direct dans la catégorie Bohrbug.

Encore plus récent, on va prendre le cas du premier Phenom d'AMD (révision B2), avec sa bogue TLB corrigée par patchage du microcode via un mise à jour du BIOS: détecté juste à sa sortie après des benchs nombreux, il a causé une révision du proc' (la B3) et du délai sur la sortie des proc's à des fréquences supérieures.

Comme quoi, un errata, ça peut bouger...

Mémoire maximale 4096 Mo, y'aurait pas une erreur XD

@k0rias: non, le 386 pouvait adresser 4 Go, puisque il adressait la RAM sur 32 bit (4 milliards d'adresses); seulement, à l'époque, aucun chipset n'était capable d'adresser une telle quantité de mémoire! Hé oui, le contrôleur de mémoire, ça ne fait pas si longtemps que cela qu'il est intégré au CPU...

Le 386 permet l'utilisation d'un fichier d'échange (swap) lequel 'bouffe' de l'adressage aussi.

À l'époque du 386 et jusqu'au Pentium inclus, le contrôleur de RAM contrôlait les échanges entre le processeur, le cache de second niveau (s'il y en avait) et la RAM.

1. le proc' a besoin d'une adresse mémoire (pour y écrire, ou lire) codée sur 32-bit: il commence par vérifier dans sa table interne que cette adresse est 'réelle' (i.e. pas attribuée au fichier d'échange); si elle est 'réelle', il passe la requête au contrôleur;

2. le contrôleur traduit cette adresse en adresse 'physique' sur la RAM installée, ou sur les plages d'adresse utilisées par les périphériques pour leur adressage direct, et effectue l'opération demandée par le processeur;

3. l'adresse demandée est en mémoire physique: en cas de présence de cache L2, le contrôleur commence par regarder dans le cache;

4. si le cache n'a pas cette adresse ('cache miss') il interroge ensuite la RAM. Sinon, il renvoit directement le contenu du cache (cache hit).

À partir du K6-3 pour AMD et du Pentium Pro pour Intel, le processeur comporte son propre contrôleur pour le cache de second niveau intégré; à ce moment-là, il n'interroge le contrôleur de RAM que si le cache ne contient pas la page recherchée: le gain de performance est notable, puisque au lieu de ne tourner qu'à la fréquence du Front Side Bus, le contrôleur du cache et le cache tournent bien plus vite.

A partir de l'Athlon64 pour AMD, et du Core i3/5/7 pour Intel, le contrôleur de mémoire est inclus sur le processeur et tourne à la fréquence de celui-ci - ce qui permet, par exemple, de 'prévoir' les prochaines requêtes processeurs, de grouper celles-ci, de les ordonner pour une plus grande efficacit... Sauts de lignes, de colonnes et de tables dans la mémoire physique sont coûteux, c'est la latence: organiser les opérations de façon à ce qu'elles se fassent en série permet de gagner de précieux cycles de rafraîchissement RAM).

C'est d'ailleurs la raison principale pour laquelle la performance de la RAM n'a de nos jours qu'un intérêt relatif: à l'époque de l'Athlon, une RAM mal configurée pouvait coûter jusqu'à 40% (!) de la puissance brute du processeur. De nos jours, ça ne dépasse pas les 5%.

(!): résultats obtenus avec un Duron 950 et 512 Mo de DDR/266: le temps de calcul de SuperPI sur 1 Mo baissait de 40% si:
- les latences étaient bassées de 3-3-3-8 à 2-3-3-5
- le temps alloué à l'adressage banque-à-banque était baissé de 2T à 1T
- la FSB processeur était synchronisée à la fréquence de la RAM (100/133 à 133/133)

Bien entendu, c'est un cas extrême: le Duron, avec ses 64 Ko de cache de niveau 2 passait son temps à interroger la RAM, et la synchro avec la RAM passait par un déblocage du multiplicateur et un léger overclock (950->1000); mais il n'était pas rare de gagner 25% de performance brute avec un Athlon juste en allant bidouiller le BIOS, quitte à diminuer la vitesse de la RAM.

Avec l'Athlon64, son cache L2 et son contrôleur intégrés, ça variait 'achement moins.