De Sys­tem/360 à RISC-V, une brève his­toire des jeux d’ins­truc­tions

Electronique S - - La Une - PRO­POS RECUEILLIS PAR FRÉ­DÉ­RIC RÉMOND (du­rant la con­fé­rence ISSCC 2018)

Pion­nier des ar­chi­tec­tures Risc à Ber­ke­ley, membre du di­rec­toire de la fon­da­tion RISC-V et di­rec­teur de re­cherche chez Google, Da­vid Pat­ter­son re­vient sur un de­mi-siècle d’ar­chi­tec­tures de trai­te­ment nu­mé­rique pour mieux éclai­rer les dé­ve­lop­pe­ments ac­tuels. Pou­vez-vous nous rap­pe­ler l’his­to­rique des ar­chi­tec­tures de jeu d’ins­truc­tions avant l’avè­ne­ment des pla­te­formes Risc?

DA­VID PATTERSONAu dé­but des an­nées 1960, IBM pro­po­sait quatre fa­milles d’or­di­na­teurs in­com­pa­tibles entre elles: cha­cune dis­po­sait d’une mi­croar­chi­tec­ture, d’un sys­tème d’en­trées/sorties, d’un en­vi­ron­ne­ment lo­gi­ciel (as­sem­bleurs, com­pi­la­teurs, bi­blio­thèques) et d’un mar­ché (fi­nance, temps réel, scien­ti­fiques…) uniques. Les in­gé­nieurs d’IBM se sont alors don­nés comme ob­jec­tif d’in­ven­ter une ar­chi­tec­ture de jeu d’ins­truc­tions unique pour ces quatre gammes, as­su­rant une com­pa­ti­bi­li­té lo­gi­cielle entre tous, qu’il s’agisse de mo­dèles 8 bits d’en­trée de gamme ou 64 bits ra­pides. Au coeur d’un or­di­na­teur, on dis­tingue le che­min de don­nées ( da­ta­path), où les nombres sont sto­ckés et les opé­ra­tions arith­mé­tiques ef­fec­tuées, et la com­mande ( control) qui or­donne les opé­ra­tions sur le che­min de don­nées. C’est Mau­rice Wilkes, un pion­nier de l’in­for­ma­tique, qui pro­po­sa que la par­tie com­mande, dont la cir­cui­te­rie po­sait de gros pro­blèmes aux pre­miers concep­teurs d’or­di­na­teurs, soit ef­fec­tuée à par­tir d’une mé­moire Rom (qui était à l’époque bien plus ra­pide que la Ram et plus éco­no­mique que la lo­gique ), in­ven­tant au pas­sage les concepts de mi­cro pro­gram­ma­tion( c’ est-à-dire de pro­gram­ma­tion à ni­veau très bas) et de jeu d’ins­truc­tions. Les in­gé­nieurs d’IBM se sont em­pa­rés de l’idée : un seul et même pro­gramme pour­rait dès lors être conver­ti dans le jeu de mi­cro-ins­truc­tions spé­ci­fique à l’or­di­na­teur cible au moyen d’un in­ter­pré­teur dé­dié. Plus on mon­tait en gamme, plus le che­min de don­nées ef­fec­tuait des cal­culs com­plexes et plus les mi­cro-ins­truc­tions étaient larges – mais, a contra­rio, elles pou­vaient alors être moins nom­breuses puis­qu’elles étaient plus puis­santes et ra­pides. Dans la fa­mille Sys­tem/360 qui en dé­cou­la à par­tir de 1964, le plus pe­tit or­di­na­teur uti­li­sait 4 000 mi­cro-ins­truc­tions de 50 bits, le plus ra­pide 2 800 mi­cro-ins­truc­tions de 87 bits. En dol­lars ac­tuels, ils étaient ven­dus entre un et qua­rante-trois mil­lions de dol­lars. IBM a en­core à son ca­ta­logue un des­cen­dant des Sys­tem/360, ce qui en fait le plus vieux jeu d’ins­truc­tions de l’in­dus­trie.

Com­ment ces sys­tèmes se sont-ils dé­mo­cra­ti­sés?

DA­VID PAT­TER­SON La tech­no­lo­gie chan­gea la donne dans les an­nées 1970. La lo­gique, la Ram et la Rom étaient sou­dain fa­bri­quées avec les mêmes tran­sis­tors, et la loi de Moore les ren­dait plus abor­dables. Les mi­cro­pro­grammes s’éten­dirent donc, avec des mi­cro-

ins­truc­tions plus nom­breuses et so­phis­ti­quées, sto­ckées en Ram (dé­sor­mais aus­si ra­pide que la Rom) pour fa­ci­li­ter les ré­pa­ra­tions : c’est l’ère des ar­chi­tec­tures à jeux d’ins­truc­tions com­plexes ou CISC. Le meilleur exemple en est le VAX-11/780 de DEC, lan­cé en 1977, et qui comp­tait un mi­cro­code de 5 120 mi­cro-ins­truc­tions 96 bits. Pen­dant ce temps, les mi­cro­pro­ces­seurs pro­gres­saient ra­pi­de­ment et s’ins­pi­raient de ces idées. In­tel, en par­ti­cu­lier, vou­lait créer après son mi­cro­pro­ces­seur 8 bits 8080 une ar­chi­tec­ture de jeu d’ins­truc­tions à l’épreuve du fu­tur. L’amé­ri­cain mul­ti­plia les idées ori­gi­nales lors du dé­ve­lop­pe­ment d’iAPX 432: ab­sence de re­gistres à usage gé­né­ral, ins­truc­tions à lon­gueur va­riable, adres­sage sur un maxi­mum de 32 bits, sys­tème d’ex­ploi­ta­tion en lan­gage Ada… Mais ce dé­ve­lop­pe­ment prit un énorme re­tard (il s’éti­ra de 1975 à 1981) et, à sa sor­tie, iAPX 432 était cher, lent et ne te­nait pas sur une seule puce en rai­son de son mi­cro­code pro­émi­nent. Voyant les re­tards s’ac­cu­mu­ler, une pe­tite équipe In­tel fut char­gée de mettre au point en trois se­maines seule­ment un jeu d’ins­truc­tions pour le suc­ces­seur 16 bits du 8080, le 8086. Dans le même temps, IBM dé­ve­lop­pait un or­di­na­teur grand pu­blic ca­pable de concur­ren­cer l’Apple 1; sa pré­fé­rence al­lait au pro­ces­seur 68000 de Mo­to­ro­la, dont le jeu

d’ins­truc­tions res­sem­blait à Sys­tem/360, mais ce der­nier avait pris du re­tard et IBM se ra­bat­tit sur une ver­sion éco­no­mique du 8086. Le fa­bri­cant es­pé­rait en vendre 250000: au fi­nal plus de cent mil­lions de PC se­ront écou­lés, fai­sant le suc­cès du 8086 et de son jeu d’ins­truc­tions x86 con­çu en trois se­maines par une poi­gnée d’in­gé­nieurs (avec un adres­sage éten­du sur 32 bits pour la gé­né­ra­tion 80386) et qui al­lait do­mi­ner l’in­dus­trie pen­dant une bonne quin­zaine d’an­nées. iAPX 432, lui, était of­fi­ciel­le­ment aban­don­né en 1986.

Mais alors, d’où vient le be­soin d’uti­li­ser des ins­truc­tions plus simples et en nombre ré­duit?

DA­VID PAT­TER­SON Les in­gé­nieurs de DEC se sont aper­çus qu’en­vi­ron 20 % des ins­truc­tions VAX re­pré­sen­tait 60% du mi­cro­code, mais seule­ment 0,2 % du temps d’exé­cu­tion : l’ar­chi­tec­ture Cisc n’était pas vrai­ment op­ti­mi­sée. Dans le même t emps, chez I BM Re­search, l’équipe de John Cocke a por­té sur les IBM Sys­tem/370 un com­pi­la­teur ex­pé­ri­men­tal qui n’uti­li­sait que de simples ins­truc­tions de charge/ sto­ckage ( load/store) et de re­gistre à re­gistre : les pro­grammes tour­naient alors beau­coup plus vite qu’avec les com­pi­la­teurs exis­tants. Tous ces tra­vaux re­mirent en cause les gros in­ter­pré­teurs mi­cro­co­dés, leurs sto­ckages de com­mandes éten­dus et leurs jeux d’ins­truc­tions com­plexes. L’al­ter­na­tive consis­tait à uti­li­ser un jeu d’ins­truc­tions si simple qu’il ne né­ces­si­tait pas d’in­ter- pré­teur mi­cro­co­dé : plu­tôt que de sto­cker l ’ i nter­pré­teur, la mé­moire r a pi de ser­vi­rait alors de mé­moire cache pour des mi­cro- ins­truc­tions di­rec­te­ment com­pré­hen­sibles par le coeur. Ce­la per­met­tait éga­le­ment d’im­plé­men­ter des ar­chi­tec­tures à pi­pe­line et donc d’ac­cé­lé­rer les ca­dences d’hor­loge. Con­ju­gués aux avan­cées de la loi de Moore, qui au dé­but des an­nées 1980 ren­dit pos­sible l’in­té­gra­tion sur une seule puce d’un che­min de don­nées 32 bits avec mé­moires caches, ces tra­vaux abou­tirent aux ar­chi­tec­tures Risc ( re­du­ced ins­truc­tion set com­pu­ter, par op­po­si­tion à Cisc). Les gains avoi­si­naient alors un fac­teur 3: à al­go­rithme équi­valent, une ar­chi­tec­ture Risc de­vait exé­cu­ter deux fois plus d’ins­truc­tions que l’équi­valent Cisc, mais chaque ins­truc­tion était trai­tée six fois plus vite. Les pro­jets Risc me­nés par les in­dus­triels et les uni­ver­si­taires abou­tirent aux suc­cès com­mer­ciaux que l’on sait (ARM, MIPS, Po­wer, Sparc, etc.) et les ar­chi­tec­tures Risc do­mi­nèrent les sta­tions de tra­vail et les ser­veurs dès le mi­lieu des an­nées 1980.

DA­VID PAT­TER­SON Pen­dant un temps, les pro­ces­seurs x86 ont sur­pas­sé les ar­chi­tec­tures Risc en s’ap­puyant sur des blocs ma­té­riels spé­ci­fiques qui tra­dui­saient le jeu d’ins­truc­tions x86 en ins­truc­tions in­ternes de type Risc ( ce qu’In­tel ap­pelle « mi­cro-opé­ra­tions » et AMD « opé­ra­tions Risc »), de ma­nière à pou­voir sin­ger les avan­cées Risc : pi­pe­lines pro­fonds, ap­pel de plu­sieurs ins­truc­tions par cycle d’hor­loge, pré­dic­tion d’em­bran­che­ment. D’où la do­mi­na­tion des pro­ces­seurs

Da­vid Pat­ter­son

In­tel et AMD ont ven­du moins de pro­ces­seurs x86 en 2016 qu’en 2007.”

x86 dans le sec­teur des or­di­na­teurs per­son­nels, mais aus­si des pe­tits ser­veurs par exemple. Mais ces ar­ti­fices re­quièrent de l’éner­gie, et l’avè­ne­ment de l’élec­tro­nique em­bar­quée, sym­bo­li­sée par le smart­phone, a re­mis les ar­chi­tec­tures Risc, plus fru­gales, sur le de­vant de la scène. Les ventes de pro­ces­seurs x86 ont at­teint leur som­met en 2011 et dé­clinent de­puis – In­tel et AMD en ont moins ven­du en 2016 qu’en 2007.

Y a-t-il des al­ter­na­tives à ces deux struc­tures?

DA­VID PAT­TER­SON La prin­ci­pale ten­ta­tive pour sor­tir du dip­tyque Risc/Cisc a ré­si­dé dans la mode des ar­chi­tec­tures VLIW ( ve­ry long ins­truc­tion

word). Proche du concept des mi­cro-ins­truc­tions éten­dues, l’ins­truc­tion VLIW, longue de plus de 100 bits, com­mande plu­sieurs opé­ra­tions qui cor­res­pondent au hard­ware du che­min de don­nées (par exemple quatre ac­cès mé­moire sui­vis de deux opé­ra­tions sur les en­tiers et de deux opé­ra­tions en vir­gule flot­tante). La concep­tion hard­ware s’en trouve sim­pli­fiée, en re­vanche il re­vient au com­pi­la­teur d’or­ches­trer de ma­nière op­ti­male les opé­ra­tions au sein de ces grandes ins­truc­tions. Au mi­lieu des an­nées 1990, In­tel a choi­si cette voie pour as­su­rer la suc-

ces­sion du jeu d’ins­truc­tions 32 bits du 80386, en cher­chant au pas­sage à prendre ses dis­tances avec AMD (qui lui aus­si avait le droit de fa­bri­quer des pro­ces­seurs x86) et se dé­mar­quer d’éven­tuels concur­rents Risc. In­tel s’est donc lié à Hew­lett Pa­ckard pour créer la mi­cro-ar­chi­tec­ture EPIC ( ex­pli­cit­ly pa­ral­lel ins­truc­tion com­pu

ting), suc­ces­seur 64 bits d’ins­pi­ra­tion clai­re­ment VLIW des ar­chi­tec­tures x86 d’In­tel et PIRISC d’HP. Le ca­len­drier ini­tial pré­voyait un échan­tillon­nage en 1997 ; In­tel dût at­tendre la fin de l’an­née 1999 pour dé­voi­ler le pro­ces­seur Ita­nium, qui ne fut réel­le­ment lan­cé qu’en 2001. Han­di­ca­pé par les pro­blèmes de com­pi­la­tion VLIW (em­bran­che­ments i mpré­vi­sibles, la­tences mé­moires va­riables, etc.) et l’ex­plo­sion de la taille du code, Ita­nium fut iro­nique- ment re­bap­ti­sé Ita­nic sur les fo­rums en ligne, et In­tel for­cé d’adop­ter l’es­sen­tiel de la mi­cro-ar­chi­tec­ture AMD64 par la­quelle AMD avait de son cô­té fait évo­lué en 64 bits le jeu d’ins­truc­tions x86. Au­jourd’hui, les ar­chi­tec­tures VLIW ne sont guère plus uti­li­sées que dans les DSP, dont les ca­rac­té­ris­tiques leur conviennent par­fai­te­ment (pro­grammes peu vo­lu­mi­neux, em­bran­che­ments très pré­vi­sibles, mé­moires caches à la­tence fixe).

DA­VID PATTERSONElles l’ont été jus­qu’à ré­cem­ment, quand trois lois fon­da­men­tales de la mi­cro­élec­tro­nique se sont com­bi­nées pour an­ni­hi­ler les re­cettes tra­di­tion­nel­le­ment uti­li­sées pour amé­lio­rer les per­for­mances des pro­ces­seurs. Pri­mo, la loi de Moore se heurte à un mur phy­sique qui ra­len­tit consi­dé­ra­ble­ment le pas­sage à des géo­mé­tries de gra­vure plus fines, avec des sur­coûts tels que seule une poi­gnée de com­po­sants à très fort vo­lume peut en bé­né­fi­cier. Se­cun­do, le prin­cipe de Den­nard, qui sta­tuait que la den­si­té de puis­sance des tran­sis­tors de­meu­rait iden­tique mal­gré leur mi­nia­tu­ri­sa­tion, a lui aus­si pris fin : il n’est pas pos­sible d’étendre la fré­quence de fonc­tion­ne­ment au­de­là d’une cer­taine li­mite sans po­ser de graves pro­blèmes d’éva­cua­tion de cha­leur. Ter­tio, la loi d’Am­dahl prouve que plus on ajoute de coeurs en pa­ral­lèle, plus le bé­né­fice de per­for­mances se ré­duit : rien ne sert donc d’ac­cu­mu­ler les coeurs de trai­te­ment nu­mé­rique sur une puce, hor­mis pour quelques tâches bien par­ti­cu­lières où le pa­ral­lé­lisme joue à plein. La ré­ponse de l’in­dus­trie a consis­té à dé­ve­lop­per des ar­chi­tec­tures de pro­ces­seurs op­ti­mi­sés pour une

Les ar­chi­tec­tures x86 et Risc semblent qua­si­ment in­dé­pas­sables…

seule tâche ou DSA ( do­main spe­ci­fic ar­chi­tec­tures), à l’ins­tar du TPU ( ten­sor pro­ces­sing

unit) de Google, dé­vo­lu à gé­rer des ré­seaux neu­ro­naux bien plus ra­pi­de­ment que les CPU et GPU tra­di­tion­nels.

Est-ce alors la fin des pro­ces­seurs, di­sons, gé­né­ra­listes?

DA­VID PAT­TER­SON Il de­meure de nom­breuses ap­pli­ca­tions re­qué­rant des pro­ces­seurs à tout faire, ne se­rait-ce que pour faire tour­ner des sys­tèmes d’ex­ploi­ta­tion ou des in­ter­faces uti­li­sa­teurs. Éton­nam­ment, trente ans après leur lan­ce­ment, les ar­chi­tec­tures Risc font en­core consen­sus : per­sonne n’a lan­cé d’ar­chi­tec­ture Cisc de­puis 1985, ni d’ar­chi­tec­ture VLIW de­puis 2000. En re­vanche, il existe un mar­ché pour des ar­chi­tec­tures Risc mo­dernes (celles qui sont au­jourd’hui lar­ge­ment uti­li­sées ac­cusent leur âge), telles que RISC-V. Dis­po­nible en open source, RISC- V n’est pas contrô­lé par une seule so­cié­té, mais ré­gu­lé par une fon­da­tion à but non lu­cra­tif. Il bé­né­fi­cie d’un quart de siècle d’ex­pé­ri­men­ta­tions Risc et peut donc trier les bonnes et les mau­vaises idées. Sa sim­pli­ci­té n’est pas le moindre de ses atouts. Il suf­fit d’une jour­née de tra­vail de huit heures pour lire l’in­té­gra­li­té du ma­nuel ISA de RISC-V; pour x86-32, ce­la pren­drait un bon mois. En outre, si la base du jeu d’ins­truc­tions RISC-V est fixe, son approche mo­du­laire per­met d’ajou­ter des ins­truc­tions en fonc­tion de l’ap­pli­ca­tion, d’adres­ser des es­paces mé­moires 32 bits ou 64 bits ou de ré­ser­ver des opé­ra­tions pour faire ap­pel à des ac­cé­lé­ra­teurs ex­ternes. En fait, en se heur­tant à des li­mites phy­siques, l’in­dus­trie de la mi­cro-élec­tro­nique doit trou­ver des so­lu­tions ar­chi­tec­tu­rales in­no­vantes pour se ré­gé­né­rer, et les coeurs DSA et RISC-V pour­raient jouer un rôle fon­da­men­tal dans cette re­nais­sance.

DA­VID PAT­TER­SON, membre du di­rec­toire de la fon­da­tion RISC- V Sur un cir­cuit com­plexe ac­tuel peuvent co­exis­ter une dou­zaine de jeux d’ins­truc­tions dif­fé­rents : est-ce vrai­ment in­dis­pen­sable ?”

≥ Lan­cée au mi­lieu des an­nées 60, l’ar­chi­tec­ture Sys­tem/ 360 d’IBM af­fiche la plus longue du­rée de vie de l’in­dus­trie.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.