x86s : Intel réfléchit à une architecture totalement 64 bits

Le reste ? Virtualisé

x86s : Intel réfléchit à une architecture totalement 64 bits

x86s : Intel réfléchit à une architecture totalement 64 bits

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Intel travaille actuellement à une simplification de son architecture x86-64 pour ne garder que le 64 bits. Le changement aurait divers avantages, mais demande de la préparation. Le fondeur est d’ailleurs à la recherche de retours sur cette idée.

Le 64 bits est présent dans tous les ordinateurs vendus depuis des années. Aujourd’hui, une machine sous Windows 11 l’est obligatoirement, puisque le système ne prend pas en charge les anciens processeurs 32 bits.

Le x86-64, ou AMD64 (puisqu’AMD était premier sur ce segment), est une extension du x86 classique, architecture qui a vu le jour avec le 8086 d’Intel (16 bits) en 1978. Le passage aux 32 bits est arrivé en 1985 avec le 80386. Il faudra attendre 2003 pour que le x86_64 arrive chez AMD, et 2004 chez Intel. Bien que la complexité et les fonctions des processeurs modernes n’aient plus grand-chose à voir avec les puces d’il y a 45 ans, l’héritage technique est là, sous divers aspects.

Le développement a privilégié avec le temps la compatibilité, avec de multiples conséquences pour les processeurs d’aujourd’hui. S’affranchir de cet héritage impose de casser la compatibilité, au moins partiellement. C’était l’idée d’Intel avec l’architecture Epic de ses processeurs Itanium, et de leur jeu d’instruction IA-64. Ces puces n’avaient cependant pas vocation à atteindre le grand public, et en dépit d’un certain succès dans le monde professionnel, il n’y eut plus de nouveau modèle après 2017, victimes notamment de la concurrence avec l’architecture x86-64, bien plus abordable.

Intel revient donc avec une nouvelle proposition, x86s (s pour simplification), visant à faire le ménage dans ses puces actuelles. Et en cas de besoin pour une ancienne fonction ? Il suffira de l’émuler.

x86s : supprimer tout ce qui peut l’être

Intel prend note de la situation actuelle : les systèmes d’exploitation 64 bits sont le standard de facto et sont capables d’exécuter des applications 32 bits si nécessaires. Heureusement d’ailleurs pour certaines entreprises prenant leur temps, comme Valve. Steam est en effet toujours une application 32 bits sur Windows et Linux, sans parler de la désastreuse variante Mac, fonctionnant avec difficulté sur les Mac équipés d’une puce Apple Silicon.

Le fondeur pose donc la question : n’est-il pas le moment de simplifier un peu tout ça ? La proposition d’Intel est ainsi de supprimer tout ce qui n’est directement nécessaire au 64 bits et d’émuler le reste, s’il y a vraiment besoin. Les anciens composants 16 et 32 bits ne sont plus utilisés que pour une seule tâche selon l’entreprise : passer le relai au 64 bits.

De nombreux éléments seraient ainsi retirés, comme le ring 0 du 32 bits, les rings 1 et 2 (car inutilisés par les applications d’aujourd’hui), les modes réel et protégé 16 bits, l’adressage 16 bits de la mémoire, les MTRR fixes, une partie des entrées/sorties, le mode CR0 Write-Through, le contrôle du flag d’interruption du ring 3, certaines instructions obsolètes, l’impossibilité de désactiver certains mécanismes comme NX et SYSCALL, XAPIC (contrôle d’interruption) pour ne plus supporter que x2APIC, ou encore les exceptions #SS et #NP.

Intel détaille point par point chaque retrait dans son livre blanc sur le x86s.

Les bénéfices attendus du grand ménage

Selon Intel, le design des puces x86s en serait d’autant simplifié, de même que le fonctionnement général de l’ordinateur. L’initialisation et le redémarrage se feraient directement en 64 bits. C’est le modèle simplifié de segmentation de ce dernier qui serait utilisé pour le support des applications 32 bits, reflétant matériellement ce que les systèmes d’exploitation font déjà logiciellement.

Pour Intel, cette simplification de la conception entrainerait celle des systèmes d’exploitation. De nombreux mécanismes ne seraient plus nécessaires, et des pans de vieux code pourraient être supprimés.

En outre, le fondeur estime que les technologies de virtualisation sont aujourd’hui largement assez avancées pour prendre en charge certaines vieilles fonctions si besoin, par exemple pour un système d’exploitation n’ayant pas été taillé sur mesure pour l’architecture x86s. Autrement dit, tous les systèmes actuels. Cela paraissait évident pour ne pas risquer une cassure, mais il valait mieux le mentionner.

« Bien que l’exécution d’un ancien système d’exploitation 64 bits sur un processeur à architecture 64 bits uniquement ne soit pas un objectif explicite, l’écosystème logiciel de l’architecture Intel a suffisamment évolué avec des produits de virtualisation pour qu’une solution logicielle basée sur la virtualisation puisse utiliser du matériel de virtualisation (VMX) pour fournir une solution permettant d’émuler les fonctions requises pour lancer les systèmes d’exploitation anciens », ajoute Intel.

Le fondeur ne l’aborde pas directement dans son livre blanc consacré au sujet, mais il y aurait nécessairement des bénéfices en matière de sécurité. En supprimant tout ce qui peut l’être, la surface d’attaque serait d’autant plus réduite, en particulier quand il s’agit de vieilles fonctions matérielles pensées à des périodes où la sécurité n’était pas aussi cruciale qu’aujourd’hui.

Quel impact au quotidien ?

Au stade du simple livre blanc, tout reste encore hypothétique. Parallèlement, sa publication montre qu’Intel avance sur le sujet et réfléchit sérieusement à la question depuis un moment. Il est probable que Microsoft a été consultée, dans l’optique d’une adaptation de Windows à cette architecture simplifiée.

Quels seraient les impacts, dès lors, si ces processeurs sortaient demain ? Il est probable qu’il y aurait certaines limitations. Certes, la plupart des applications et jeux récents sont en 64 bits, mais c’est loin d’être une règle absolue. On peut imaginer des machines qui démarreraient un peu plus vite et globalement plus sécurisées, mais il faudrait vérifier la compatibilité avec la totalité du parc logiciel, ce qui mènerait nécessairement à quelques désillusions.

Car si la virtualisation donne d’excellents résultats sur les applications classiques, c’est en revanche plus compliqué dans le domaine du jeu. Le passage à un matériel purement 64 bits aurait des conséquences sur bon nombre de titres plus ou moins anciens, sans parler de tout ce qui touche au rétrogaming et aux émulateurs.

C’est toute l’ambivalence de la situation : même sur un Windows 11 – donc forcément 64 bits – le parc logiciel peut encore être très hétérogène. Seul l’ancien code 16 bits ne peut vraiment plus y fonctionner, du moins pas sans virtualisation. Avec la proposition d’Intel, tout code 32 bits serait obligatoirement virtualisé, et si l’on sait que les performances sont excellentes sur tout ce qui touche la bureautique, il en irait autrement dès que le besoin de puissance se ferait sentir. Tout ce qui touche à la 3D poserait également vite problème.

Attention toutefois, car Intel évoque surtout des pistes de réflexion. Si l’entreprise se montre sérieuse dans son projet, il faudra au bas mot attendre plusieurs années avant que le x86s se concrétise. On peut aussi parier qu’AMD prend bonne note de ce projet et va réfléchir au sujet.

Commentaires (33)



Le x86-64, ou AMD64 (puisqu’AMD était premier sur ce segment)




C’est surtout AMD qui a créé les instructions 64bits du x86-64, et ca a été appelé AMD64 pour le différencier du 64bits version Intel (utilisé notamment dans les Itanium) :chinois:


Oui Itanium, j’avais zappé.
Et qui était quand à lui, T O T A L E M E N T incompatible, pour nous forcer à migrer, déjà à l’époque :phiphi:
Ben ça appuie ce que je viens d’écrire.



Soit Intel sera forcé nous laisser une rétrocompatibilité car la concurrence va rester sur le filon (AMD64), soit la concurrence risque vraiment de remplacer son offre et de migrer tout le monde (ARM)


Donc le temps que les compilateurs et interpréteurs soient mis à jour, et que les application soient compilés dans ce nouveau mode x86s, on aura largement le temps de voir venir les changements.


Si je me trompe pas, on pretend souvent que les perfs inegallées des CPUs ARM d’Apple est gagné grace a l’abandon du 32 il y a quelque années.
j’ai dans l’idée que ce meme menage serait bien benefique chez X86 aussi
et qand on voit les M1-3 qui sont capable d’emuler des programmes X86 de maniere plus fluide que sur du natif X86 ….
bref, ca me semble une bonne idée ce menage.


Et c’est pas faux.



Pour te faire une idée, désinstalles tous les paquets d’architecture x86-32 sur ta distribution ubuntu …



Moi, j’ai remarqué “un chouillat” de poil de perf sur un OS qui était déjà minimalistes (ça m’a pas supprimé de service car j’avais déjà fait sauter tout service / paquet inutile supprimé/désactivé mais dans le respect des dépendances de paquetage).


il n’est pas du tout écrit qu’intel ne supportera plus le 32bits, c’est la couche 16bits qui disparait : actuellement le CPU boot en mode 16bit 8086 au cas où il devrait démarrer DOS, puis le BIOS le switch en mode moderne32-64bits.
Quand au 64-32bit c’est le même mode pour le processeur: en 32bits il n’utilise que la moitié des registres. L’autre moitié de chaque registre peut être utilisée si le programme a été compilé pour: en 32bits mais avec le support de plus de registres. Ce qui n’est jamais le cas, les programmes 32bits sont compilés en mode 686 (pentium premier du nom), et n’exploite donc que la moitié des registres d’un CPU.



Donc concrètement ça change le démarrage de la machine (donc plutôt au niveau UEFI) par sûr que ça impacte l’OS, et ça n’impactera pas les applications habituelles 64bits et 32bits.


l’idée me semble bonne, et pas forcément aussi problématique du coté des anciens jeux / émulation :
les jeux “encore 32 bits”, qui auraient donc besoin d’émulation, ne sont probablement pas les derniers AAA, donc à moins de faire des monocoeurs à 1.5ghz, je soupçonne que même le plus petit x86s aurait suffisamment de patate pour que l’émulation soit invisible, et au pire, cette archi n’étant pas encore sortie, il “suffit” de calibrer le plus faible pour qu’il ait des performances suffisantes (au pire via des circuits dédiés à la virtualisation qui ne seraient pas nécessaires sur les modèles supérieurs, mais l’ajout de circuits dédiés va à l’encontre de la simplification :s)



au pif, “si ça sortait demain”, il n’y aurait aucun problème : il reste la génération actuelle pour tout ce qui ne marcherait pas, et en sortant des puces au moins “milieu de gamme”, soit la puissance “perdue par l’émulation” et négligeable, soit c’est un cas particulier imposant de rester sur la génération actuelle le temps que la partie logicielle évolue



par contre, intel peut torpiller l’idée tout seul commercialement, si la seule option c’est acheter un “itanium v2” 2000€ sans facilité de retour si c’est un cas particulier incompatible avec les logiciels utilisés, ça va faire un flop
en revanche, si intel met en avant cette nouvelle architecture et propose un truc du genre “échange contre un 13*” (avec une équivalence selon le niveau de perfs) si constatation d’une incompatibilité logicielle dans les 90 jours, bah les clients seraient confiants pour tester, et même si y’a 30% de retours, ça serait un énorme succès


C’est quand même curieux que l’on entende aucune coordination entre Intel et Microsoft au sujet de l’architecture x86S.



A chaque fois que l’un des deux a travaillé seul en criant que “cette fois c’est la bonne”, ça a donné une prolongation de la rétrocompatibilité.




  • NT4 / W9x > pour tuer le 16bit (qui n’est pas totalement mort hein).

  • la bordée de Windows ARM

  • W10 a tenté d’éjecter le 32 bit aussi …



x86S sans aucune rétrocompatibilité native 32bit ?
Cela risque tous de nous faire migrer dans les 10 ansen processeur RISC et nous nous dirons qu’on était bien bête de rester sous Intel “car c’était ZE référence”. On y va, petit à petit mais on y va … vers la distribution Ubuntu Windows arm64 !



Il va falloir que je me dépèche de réinstaller Doom II pendant que je peux encore y jouer tiens :roll:



(reply:2133832:Daïmanu)




y’a qua voir l’arrivée du 64 bits sur i386/i686 par AMD puis Intel, ça a mis quelques années avant que l’OS grand public de MS le gère, puis que ça se démocratise.


Je me suis posé une question en lisant cet article : on a des processeurs 32 bits, 64 bits, mais est-ce qu’un jour on va voir arriver des processeurs 128 bits ? Y-a-t-il un intérêt à cela ?



Mes recherches ne m’ont pas mené plus loin que sur des rumeurs récentes ( https://www.silicon.fr/pas-de-processeur-128-bits-pour-arm-91094.html ) ou des blagues de 2009 ( https://www.cnetfrance.fr/news/successeur-windows-7-architecture-128-bits-39708838.htm ).


On peut adresser tellement de données déjà avec du 64bit, que je ne vois pas l’intérêt d’un 128bit. Niveau RAM, au pire au pourrait refaire un PAE. Niveau calcul, on a déjà des instructions en 512bit (genre AVX)



Avec la proposition d’Intel, tout code 32 bits serait obligatoirement virtualisé




Non le support d’applications 32 bits de change pas, elles ne pourront en revanche plus s’exécuter en espace kernel (ring0). C’est déjà le cas sur Windows 11.



processeurs Itanium, et de leur jeu d’instruction IA-64 (…) et en dépit d’un certain succès dans le monde professionnel, il n’y eut plus de nouveau modèle après 2017




Alors là, je suis curieux de savoir chez quelle profession l’Itanium a été un succès. Parce que de ce que j’ai pu en voir dans mon domaine, ça a été un véritable four.



Ce qui a tué l’Itanium, c’est qu’avec son architecture VLIW, toute la complexité était reportée dans le compilateur, et le compilateur n’était pas prêt. Au final, il allait moins vite que des processeurs moins cher.


l’Itanium a été au départ conçu pour concurrencer mes Power IBM dans les systèmes où l’erreur n’est pas permise en fonctionnement.



Tu en trouves/trouvais donc dans la finance/le paiement, la chimie (Total), peut être dans le ferroviaire, l’aviation.



C’était clairement pas un système pour foutre dans une PME, vue le tarif c’était pour les grands comptes.


En ce qui me concerne je n’avais aucune idée que les Itanium avaient duré aussi longtemps, pour moi c’était un échec commercial total qui n’était resté que 2-3 ans sur le marché.


loser

En ce qui me concerne je n’avais aucune idée que les Itanium avaient duré aussi longtemps, pour moi c’était un échec commercial total qui n’était resté que 2-3 ans sur le marché.


La news parle de 2017 pour la fin des Itanium, mais le dernier modèle est sorti en 2012. Il est donc resté 5 ans au catalogue sans être renouvelé.


1978 : 16 bits
1985 : 32 bits
2003 : 64 bits
2030 ? : 128 bits


Dans l’article, il est question d’émulation et virtualisation. C’est quoi la différence entre les deux concepts ? Ici, on a l’impression que les deux termes sont interchangeables.


Ce n’est pas interchangeable. Dans les grandes lignes, la virtualisation consiste à présenter un matériel virtuel pour des applications et OS pouvant fonctionner sur le même matériel que sur la machine utilisée. L’émulation, c’est présenter un matériel d’architecture différente, comme le fait par exemple Apple avec Rosetta, qui s’occupe de faire fonctionner les applications prévues pour x86 sur les Mac M1/M2, ou comme les émulateurs de consoles.


l’émulation vise à simuler le fonctionnement d’une autre architecture processeur
la virtualisation vise à encapsuler / simuler / isoler un système (un os par exemple)



ici je suppose qu’il s’agit d’avoir une machine virtuelle qui va émuler un système 32 bits
émulation, car le processeur “réel” ne contient pas les instructions 32 bits, il y aura donc une couche logicielle de conversion “à la volée” 32 -> 64bits
virtualisation, car l’ensemble serait encapsulé / isolé avec accès a des ressources physiques limitées



sans virtualisation, on pourrait imaginer une appli 32 bits foireuse qui peut corrompre l’os, alors que si c’est virtualisé, en théorie l’appli 32 bits n’a accès à rien de l’os et ne peut pas corrompre l’os (sauf si faille dans la virtualisation, mais ça limite la surface d’attaque)



edit : archi grillé :D



Z_cool a dit:


Si je me trompe pas, on pretend souvent que les perfs inegallées des CPUs ARM d’Apple est gagné grace a l’abandon du 32 il y a quelque années.




Voici mon avis:




  • x86 a été conçu quand la RAM coûtait cher, était très lente, et on programmait encore en assembleur. D’où des instructions capables de faire des boucles pour comparer des chaînes, ou des instructions pour faire du calcul décimal en BCD directement dans le CPU.

  • Dans les années 80, le prix de la RAM et la vague des langages compilé a balayé l’usage de ces instructions (car les compilos ne savent pas quand les générer)

  • D’où le constat fin 80 lors de la conception des ARM que seules les instructions +,-,*, les comparaisons, les échanges mémoire et les sauts sont utiles



ARM a continué avec ses instructions relativement limitées



Mais côté x86, on est passé du CPU tout câblé au CPU super scalaire qui réinterprète l’assembleur en autre chose, multiplie les registres en interne, et exécute tout sur des coeurs plutôt RISC.



Les anciennes instructions ne “plombent” pas vraiment le CPU (certaines sont déjà “émulées” via du microcode), mais les différents types d’accès mémoire sont certainement une plaie.



Intel ne supprime pas d’après le document le 32 bits, les instructions perdurent, il faut “juste” fournir un environnement 32 bits dans un OS 64. Par contre le mode VM86 disparaît et différents systèmes de “sécurité” jamais utilisés.




jpagin a dit:


Je me suis posé une question en lisant cet article : on a des processeurs 32 bits, 64 bits, mais est-ce qu’un jour on va voir arriver des processeurs 128 bits ? Y-a-t-il un intérêt à cela ?




Si le “128-bits” correspond à la largeur du bus mémoire, c’est encore un peu loin … On n’arrive pas à créer un ordi qui aurait la RAM maximale gérée par du 64 bits (par ailleurs, je doute que les ordis câblent les 64 bits). Si c’est pour la largeur de bus… Sauf à vouloir un CPU qui dépote avec la RAM (comme les cartes graphiques), c’est un peu coûteux sur des ordis qui ont de la RAM en barette: il faudrait passer les 128 lignes de bus de transfert sur la carte mère, c’est coûteux.



Par contre je peux te rassurer: la plupart des ordis ont des instructions 128 bits (SSE, MMX), 256 ou 512 bits (AVX)



the_Grim_Reaper a dit:


l’Itanium a été au départ conçu pour concurrencer mes Power IBM dans les systèmes où l’erreur n’est pas permise en fonctionnement.




Et pourtant, tous les systèmes Itanium que j’ai pu manipuler étaient bien plus instables que n’importe quelle machine Opteron.


J’ai déjà vu des systèmes stables devenirs instables à cause de ce qui était installé dessus.
J’ai déjà vu une BDD Oracle mettre une infinité de temps pour ajouter une colonne dans une table.
Quand les outils sont mal codés, ils sont mal codés, c’est pas la faute du système sous jacent.



Fin de support logiciel HP en 2021 il me semble



luxian a dit:


Oui Itanium, j’avais zappé.
Et qui était quand à lui, T O T A L E M E N T incompatible, pour nous forcer à migrer, déjà à l’époque :phiphi:




L’Itanium n’était pas pour nous forcer à migrer, mais pour le monde professionnel pour proposer quelque chose de neuf et propre qui pourrait aller plus loin que le “x86” ; l’inconvénient a été que la performance dépendait pas mal des compilateurs, qui étaient plus complexes à mettre au point vu la façon dont ça a été conçu (regroupement d’instructions).




(quote:2133861:alex.d.)
Ce qui a tué l’Itanium, c’est qu’avec son architecture VLIW, toute la complexité était reportée dans le compilateur, et le compilateur n’était pas prêt. Au final, il allait moins vite que des processeurs moins cher.




Merci pour la précision “VLIW” j’avais oublié le terme.




(quote:2133891:alex.d.)
Et pourtant, tous les systèmes Itanium que j’ai pu manipuler étaient bien plus instables que n’importe quelle machine Opteron.




Qu’appelles-tu instable ? De toutes façons, c’est lié à l’OS ou l’applicatif, pas au processeur.



Wosgien a dit:


Voici mon avis:




  • x86 a été conçu quand la RAM coûtait cher, était très lente, et on programmait encore en assembleur. D’où des instructions capables de faire des boucles pour comparer des chaînes, ou des instructions pour faire du calcul décimal en BCD directement dans le CPU.

  • Dans les années 80, le prix de la RAM et la vague des langages compilé a balayé l’usage de ces instructions (car les compilos ne savent pas quand les générer)




Les compilos savaient les générer (ne serait-ce que les boucles), on ne faisait pas que de l’assembleur à l’époque. Pour le BCD je ne sais pas, j’en ai fait en assembleur pour m’amuser à faire des calculs de grands nombres, mais j’ai fait autrement ensuite avec un compilo, comme stocker 9 chiffres décimaux dans un mot de 32 bits (sur Amiga 68000 qui était déjà avec des registres 32 bits).



Si le “128-bits” correspond à la largeur du bus mémoire, c’est encore un peu loin … On n’arrive pas à créer un ordi qui aurait la RAM maximale gérée par du 64 bits (par ailleurs, je doute que les ordis câblent les 64 bits). Si c’est pour la largeur de bus… Sauf à vouloir un CPU qui dépote avec la RAM (comme les cartes graphiques), c’est un peu coûteux sur des ordis qui ont de la RAM en barette: il faudrait passer les 128 lignes de bus de transfert sur la carte mère, c’est coûteux.




En fait en x64, les adresses mémoire sont en 48 bits, avec possibilité d’extension dans le futur.
Cher ARM ils sont aussi en 48 bits, avec par exemple des signatures de pointeur dans le reste.



Ca permet 256 To de RAM.


Quelqu’un a une idée de l’impact de la taille variable des instructions sur la vitesse d’exécution ?
(ie, ARM32 => 16 bits en thumb our 32 bits en normal, et je soupçonne que tout est sur 64 bits en ARM64, à moins qu’ils n’aient aussi du 32… contre 0-15 octets sur x86-64… donc déjà faut décoder, et en plus l’alignement n’existe pas…)



OlivierJ a dit:


Les compilos savaient les générer (ne serait-ce que les boucles),




Pour certaines boucles, ça devait fonctionner. Toutefois, LOOP et un compteur dans CX ne fait pas tout.



De mémoire, c’était très limité (Turbo Pascal, Turbo C). Et souvent sans aucune optimisation sur les registres (capables de de relire dans AX un emplacement mémoire qu’ils viennent d’écrire avec BX…). De même, nu code en C qui fait une division et récupère le reste se voyait exécuter 2 fois la division, alors que le reste était donné déjà par la 1ère division.
D’ailleurs en ARM première version, ils trouvaient que la division c’était superflu…



Les librairies standards avaient les instructions ASM spécifique, mais dans un algo, jamais (du temps du 16 bits) je n’ai vu la version compilée utiliser les instructions MOVS ou CMPS qui permettaient de copier/comparer des espaces mémoire.



ensuite on s’est vite retrouvé avec les 486 et surtout pentium, donc écrire de l’assembleur pouvait être contre productif.



OlivierJ a dit:


L’Itanium n’était pas pour nous forcer à migrer, mais pour le monde professionnel pour proposer quelque chose de neuf et propre qui pourrait aller plus loin que le “x86” ; l’inconvénient a été que la performance dépendait pas mal des compilateurs, qui étaient plus complexes à mettre au point vu la façon dont ça a été conçu (regroupement d’instructions).



Oui mais bon, ce n’est pas comme si à l’époque on avait pas eu une flopée d’autres architectures proffessionnelles. Itanium, c’était juste “un de plus” dans la catégorie “architecture pro ciblant le marché professionnel”. Power, Alpha, Sparc, … étaient déjà bien implantés et stables.




L’Itanium était juste une erreur de calcule, une tentative d’Intel d’exister sur un segment trop difficile à convaincre. (quand tu vois des entreprises comme des banques mettre fin prématurément au leasing de machines Itanium pour libérer de l’espace en centre de calcule en mod “oops on s’est trompés, on va rajouter quelques Regattas à la place”, tu sais que c’est mal barré pour le produit)



ragoutoutou a dit:


Oui mais bon, ce n’est pas comme si à l’époque on avait pas eu une flopée d’autres architectures proffessionnelles. Itanium, c’était juste “un de plus” dans la catégorie “architecture pro ciblant le marché professionnel”. Power, Alpha, Sparc, … étaient déjà bien implantés et stables.




Mais c’est difficile de prévoir qui va devenir plus ou moins “leader” sur le marché, pour ma part je pensais qu’Intel resterait cantonné à la bureautique et que Alpha, Sparc ou Power allait beaucoup plus dominer.




L’Itanium était juste une erreur de calcule, une tentative d’Intel d’exister sur un segment trop difficile à convaincre.




Perso je n’aurais pas pensé que l’architecture Intel x86 allait perdurer aussi longtemps, je pensais qu’elle se ferait balayer par des architectures CPU plus propres et prometteuses (rien que l’assembleur x86 c’est dégueu je trouve, quand on vient du 6502 ou du 68000, sans parler de modes d’adressages un peu tordus, là où le 68000 a une belle architecture orthogonale avec adressage plat), comme celle qui tu as citées plus haut.



OlivierJ a dit:


Mais c’est difficile de prévoir qui va devenir plus ou moins “leader” sur le marché, pour ma part je pensais qu’Intel resterait cantonné à la bureautique et que Alpha, Sparc ou Power allait beaucoup plus dominer.




Le problème de toute architecture cpu reste l’écosystème… Quand l’Itanium a été introduit, il n’y avait pas grand chose comme écosystème pour le soutenir. Bref, comme solution généraliste, il n’était pas prêt et pour les niches genre DB, il avait beaucoup de monde à convaincre.




Perso je n’aurais pas pensé que l’architecture Intel x86 allait perdurer aussi longtemps, je pensais qu’elle se ferait balayer par des architectures CPU plus propres et prometteuses (rien que l’assembleur x86 c’est dégueu je trouve, quand on vient du 6502 ou du 68000, sans parler de modes d’adressages un peu tordus, là où le 68000 a une belle architecture orthogonale avec adressage plat), comme celle qui tu as citées plus haut.




Moi, non-plus, les premiers Xeon c’était de la grosse blague… En fait, si le x86 est devenu si important, c’est sans-doutes en partie à cause d’AMD qui a commencé à utiliser des technologies d’interconnexion sérieuses comme l’hypertransport qui rendaient le multi-socket enfin exploitable correctement… et l’AMD64 qui permettait d’avoir une quantité de mémoire supérieure à 4GiB, ouvrant la porte à des opérations plus sérieuses en entreprise (db, virtualisation, …).
Sinon je partage sans réserves ton avis pour l’assembleur sur x86…


En fait ça existe déjà et ça s’appelle ARM64 :-D



ragoutoutou a dit:


Moi, non-plus, les premiers Xeon c’était de la grosse blague… En fait, si le x86 est devenu si important, c’est sans-doutes en partie à cause d’AMD qui a commencé à utiliser des technologies d’interconnexion sérieuses comme l’hypertransport qui rendaient le multi-socket enfin exploitable correctement…




Et à bas coût. De même que pour le monde des PC, le monde des serveurs a été envahi de x86 car c’était moins cher et toutes les marques pouvaient en faire.



Lors qu’à part IBM pour les power, Sun pour les sparc et digital pour les alphas, ça ne se bousculait pas au portillon.


Fermer