Sommaire
Préambule
Cet article est complexe avec beaucoup de vocabulaire technique en anglais. Vous pouvez consulter la page CPU, nouvellement créée dans le wiki de Linuxfr pour bien comprendre le fonctionnement des processeurs et des architectures modernes.
Si vous connaissez bien les processeurs, n’hésitez pas à enrichir ce wiki ou à commenter cette dépêche pour donner des explications à tout le monde.
Présentation de l’AltairX
Approche de ce CPU
L’AltairX tente d’avoir de bonnes performances, tout en conciliant simplicité d’implémentation et économie de transistors et d’énergie. Pour cela, il décharge la complexité vers le compilateur, qui gère et indique les diverses optimisations à effectuer. C’est aussi le compilateur qui indique le nombre d’instructions à exécuter en parallèle de façon explicite : ici, deux instructions par cycle.
L’AltairX pourrait très bien faire quatre instructions par cycle et être meilleur que les Ryzen Zen 5 ou Intel 13900, mais comme il est très compliqué d’avoir autant d’instructions en parallèle de manière statique1 sur un processeur généraliste, Kannagi a décidé de le faire à deux instructions par cycle pour le moment, car une plus grande complexité n’amène que des gains minimes : avec plus d’instructions par cycle, il faudrait trouver constamment des instructions à exécuter pour exploiter au maximum le CPU.
Sur un processeur généraliste, le processeur a souvent tendance à s’arrêter sur un if et surtout, c’est beaucoup moins parallélisable (on ne fait pas constamment du multimédia, mais on traite du code avec énormément de structure de contrôle if, else, switch). On considère généralement qu’un code binaire a 20% de branchement (une instruction sur cinq). C’est pour cela que, même les processeurs récents d’AMD ou Intel ne dépassent pas trois ou quatre instructions par cycle en moyenne. Deux instructions par cycle restent très honorables, et donnent de bonnes performances.
L’AltairX a 64 registres : 56 registres « réels » et 8 registres spéciaux qui servent pour le bypass. Le bypass est une technique d’optimisation qui intervient dans la première des quatre grandes tâches d’optimisation :
- Résoudre les dépendances de données
- Paralléliser les instructions
- Optimiser les conditions
- Optimiser les caches
La résolution des dépendances s’optimise soit via le renommage de registre, soit via le bypass. Le renommage de registre sert quand on a les mêmes registres utilisés dans deux opérations, mais pas réellement de dépendance entre elles. Dans ce cas, on peut renommer les registres pour résoudre le problème. Le principe du bypass est qu’on ne passe pas par les registres, et qu’on lie deux unités de calcul directement pour éviter que le CPU se bloque le temps de lire/écrire les registres entre les deux instructions. La difficulté du bypass est qu’il demande au processeur pas mal d’analyse pour qu’il le fasse de lui-même, et que le débogage peut être fastidieux. Donc, sur l’AltairX le bypass est explicite ; c’est au compilateur de bien savoir l’utiliser, l’implémentation ne fait aucune vérification.
Pour les conditions, l’AltairX n’a aucune prédiction de branchement. La raison est que son pipeline est court (six étapes, ou stages, détaillés ci-dessous), ce qui fait que les branchements ont un coût de un à cinq cycles (tout dépend de comment le compilateur arrive à optimiser). C’est relativement faible vu qu’une mauvaise prédiction sur le x86 fait environ vingt cycles.
Ce choix de ne pas faire de prédiction de branchement est un compromis pour faciliter l’implémentation.
À la place de la prédiction de branchement, les conditions sont en delay slot, ce qui veut dire que tout le branchement s’exécute avec un cycle de retard. Pour optimiser un peu les branchements, deux instructions sont rajoutées : un CMOVE qui est un move conditionnel, et l’instruction LOOP, qui permet d’exécuter un for assez rapidement.
Genèse
Souvent déçu par x86 et son architecture qu’il trouve mal faite, mais aussi par la complexité de la programmation sur PS2 et PS3, Kannagi s’est inspiré du MIPS, des VU de la PS2, du CELL de la PS3, d’une partie de l'ARM et du M68000 pour la syntaxe.
Le nom combine une étoile et un X pour se démarquer et faire référence système Unix ou la lettre X est souvent utilisée.
L’ISA de l’AltairX
L'ISA, acronyme d’Instruction Set Architecture, c’est l’architecture du processeur. L’ISA de l’AltairX est assez simple :
- il y a 1 bit de pairing pour indiquer une ou deux instructions par cycle,
- 7 bits pour l’opcode, cette taille permet 128 instructions, ce qui est un peu limite — c’est un peu son « défaut » et Kannagi s’arrache les cheveux pour trouver des solutions avec cette contrainte ;
- 2 bits pour indiquer la taille des opérations (8/16/32/64 bits) — c’est l’équivalent de faire un
char short int long en C ou un u8 u16 u32 u64 en Rust.
- et 3 x 6 bits pour les registres.
Les instructions sur le premier et le second Opcode peuvent être différentes, c’est un avantage ! Du coup l’AltairX tourne autour de 150-160 instructions différentes (instruction SIMD compris).
Les VLIW fonctionnent avec des bundles (un groupe d’instructions). L’AltairX a un groupe de deux instructions, donc on dispose de 64 bits. Mais l’avantage du bundle, c’est que l’on peut combiner les deux instructions soit pour en faire une plus évoluée, soit pour faire des immédiates plus grandes. Attention à ne pas confondre la taille de l’instruction et celle des opcodes, par exemple sur le RISC-V les instructions font 32 bits, l’opcode bien moins.
Les caches de l’AltairX
La plupart des architectures gèrent les caches de façon conventionnelle et ne sortent pas des sentiers battus. Pourtant les caches sont primordiaux et il est important d’inventer des façons plus originales, voire carrément « exotiques » de les gérer. L’AltairX possède ainsi trois « caches » ou pour être plus exact deux caches plus un SPM ou scratchpad memory :
- Le CPU a un cache lecture et un cache écriture. Pourquoi cela ? D’une part parce que ça permet d’avoir une lecture bien plus rapide, et d’autre part parce que ça évite de vider le cache inutilement en cas de lecture seule. Une chose dérangeait Kannagi avec les optimisations sur PC x86, c’est que lorsqu’on a une grosse quantité de données à gérer (par exemple 32 Mo), on va « vider le cache » pour y mettre ces données et tout le reste sera ralenti.
- Le SPM est une version très manuelle des caches. Un cache est généralement automatique et transparent, même si vous codez en assembleur vous ne savez pas exactement ce qui est en cache ou pas. Le SPM permet de dire ce que vous voulez y mettre. L’avantage « ultime » c’est que le SPM n’a jamais de défaut de cache ! Comme dans beaucoup de consoles, le SPM de l’AltairX fonctionne avec un DMA, ce qui présente beaucoup d’avantages : on peut en faire un double buffer pour gérer ses données, ne pas avoir de cache miss et ne pas avoir à vider le cache.
Les CPU Intel et AMD utilisent du 8 way pour les caches L1, les caches L2 sont du 8 ou 16 way et les caches L3 du 16 way. Cela rend ces caches très performants avec peu de conflits d’adresses, mais ce sont aussi des caches relativement lents. Pour l’AltairX, Kannagi envisage idéalement du 4 way (ou 2 way au pire). Sur les premières versions de l’AltairX, il n’y aura que des caches L1. Kannagi ne compte pas mettre de L3, car plus vous avez de niveaux de cache, plus cela ralentit les accès à la RAM. De la même façon, Apple pour les M1 et M2 n’utilise pas non plus de cache L3.
Il existe bien sûr pas mal d’algorithmes de cache, celui de l’AltairX utilisera le PLRUm.
L’architecture de l’AltairX
L’architecture interne de l’AltairX se décompose en six étapes exécutées en parallèle (voir l’exemple de la bouteille) :
- Fetch
- Decode / Execute BRU
- Read Register
- Execute
- Memory
- Write Back
La différence avec un MIPS (de cinq stages) c’est le Read Register : celui de l’AltairX sera forcément plus « long », parce qu’on a beaucoup de registres à lire et à écrire. Mais aussi pour qu’il puisse monter facilement en fréquence. Reprenons le pipeline :
- Le Fetch est donc capable de fournir 64 bits (8 octets) par cycle pour fournir deux instructions.
- Ensuite le Decode relativement simple, mais le Decode gère aussi les branchements en lisant un register flag interne et/ou des registres internes au BRU.
- Le Register fait donc six lectures et deux écritures de registre par cycle.
-
Execute exécute les instructions à proprement parler donc ALU/LSU ici, sur le LSU il génère l’adresse.
-
Memory lit le cache L1 (s’il n’y a pas de cache miss, sinon ça fait plus d’un cycle), sur l’ALU cette étape est vide.
-
Write Back indique la fin du pipeline et l’envoi de l’écriture du registre.
Ensuite l’AltairX a deux ALU, deux LSU, deux FPU, un BRU (Branch Unit), un MDU (MulDiv Unit), un EFU (Extent Float-point Unit, pour les 'div', 'sqrt', 'sin', etc.), un FPU-D (FPU pour les doubles) et un DMA. À titre de comparaison un processeur AMD dispose de quatre ALU, quatre « LSU » (Appelé AGU) et quatre FPU.
Dans un premier temps, le FPU ne respectera pas à 100% le standard IEEE, parce que le respecter totalement prendrait trop de cycles. Plus tard, l’AltairX gèrera peut-être les half float (float de 16 bits).
Quelques CPU remarquables qui ont inspiré l’AltairX
Trois processeurs ont tenté des approches très différentes de ces problèmes :
- l’Emotion engine de la PS2 ;
- le CELL de la PS3 ;
- l'Itanium d’Intel/HP.
Beaucoup ne le savent pas mais l’Emotion engine et le CELL sont très ressemblants. Bien sûr ce n’est pas la même ISA : l’un est sur du MIPS avec des VU et l’autre sur du PowerPC avec des SPE. Mais le principe est le même : un processeur « standard » superscalaire in order et d’autres processeurs VLIW. Ces processeurs VLIW tentaient de résoudre un problème existant déjà à l’époque : « la latence de la RAM ».
L’exploit qu’arrivent à réaliser ces machines est qu’il est possible d’atteindre leur chiffre théorique, parce que la SPM (une mémoire interne dont il sera question plus loin dans cette dépêche) ne provoque aucun défaut de cache. De plus ces processeurs VLIW sont bien conçus pour permettre facilement deux instructions par cycle, y compris avec une division dessus.
Le souci c’est qu’il était compliqué de coder dessus ; et surtout ils n’avaient pas vocation à être des processeurs généralistes.
L’Itanium est vraiment unique : il a créé un type de micro architecture à lui tout seul. Il avait des bundles (un groupe d'opcode) de 128 bits pouvant exécuter trois instructions par cycle, voire plus (étant en partie superscalaire, il pouvait exécuter deux bundles par cycle, soit six instructions par cycle).
Le CELL et L’Itanium ont deux visions différentes, le CELL voulait éviter les cache miss, et l’Itanium exploser le compteur d’instructions par cycle. Mais les deux avaient le même souci, un compilateur beaucoup trop complexe qui n’arrivait pas à gérer leur architecture exotique. Pourtant, ce sont ces processeurs qui ont donné à Kannagi l’idée de son processeur AltairX, suivant deux axes :
- s’inspirer des processeurs dédiés aux consoles et en faire des processeurs généralistes ;
- faire une ISA pas trop complexe mais qui permet néanmoins d’avoir des informations du compilateur pour optimiser au mieux.
Interview de Kannagi
Pourquoi un nouveau CPU et pas le RISC-V ?
Alors de base on pourrait souvent me dire « pourquoi tu n’utilises pas du RISC-V ? » Je ne suis pas un fan inconditionnel du RISC, pour la simple raison que pour moi l’ISA doit représenter en partie le fonctionnement interne du processeur. De plus, j’ai toujours une préférence pour MIPS et je trouve qu’on fonde peut-être trop d’espoirs pour « rien » sur le RISC-V qui est un MIPS mis au goût du jour. En second point, RISC-V se veut trop « simpliste ».
Vous avez surement entendu dire que le RISC ne fait que des trucs simplistes, et le CISC non. Oui et non, mais ceux qui conçoivent RISC-V (qui sont aussi les géniteurs du RISC) restent attachés à cette idée. C’est une critique récurrente que reçoit RISC-V : il se veut trop simpliste, il veut toucher à la fois les microcontrôleurs et les ordinateurs haute performance, tout en étant facile à émuler et pédagogique.
Alors il réussit pas mal de ces choses, mais bien sûr au prix de beaucoup de compromis. Si vous voulez mon avis, je pense que ARM restera un RISC bien plus performant que le RISC-V, il est bien plus pragmatique dans sa conception.
L'ISA du RISC-V est loin d’être parfaite. Je vais éviter les différents points que beaucoup trouvent « problématiques », mais ceux qui conçoivent RISC-V répondent : « pas de souci, en Out of Order on résoudra ces défauts ». Alors oui c’est vrai, ils n’ont pas tort, le x86 y arrive très bien ! Mais du coup quel intérêt de faire du RISC-V en se disant « pas grave en y allant au bazooka on y arrivera !» ?
L’autre point est que le RISC-V se dit open-source, ce qui est exact pour l'ISA, mais pas pour son implémentation. Comme je l’avais dit, c’est un peu comme dire que l’API Linux est open source, mais que son code source ne l’est pas. C’est un peu ça le souci du RISC-V vendu « open source » pour le hardware. Et donc que l’ISA soit « ouverte » de mon point de vue n’est pas très important ? Il existe de nombreuses ISA ouvertes maintenant (Open RISC, openPower, openSparc, même le MIPS récemment !).
Et le point forcément qui me gêne le plus, le RISC-V n’est pas forcément un bon processeur in-order. Et sa seule proposition alternative est donc de faire du superscalaire out of order, technologie relativement complexe et coûteuse à faire. J’ai pu lire ici entre autres que SiFive sera le futur Intel ? Alors je ne le pense pas. C’est là tout le souci, si demain Intel ou AMD veulent faire du RISC-V, ils pourront le faire, et bien mieux que n’importe quelle entreprise actuelle. Cela fait 30 ans qu’ils font du Superscalaire Out of Order pour les hautes performances, ils ont créé un gros fossé pour le ticket d’entrée dans ce genre de technologie.
Quelles sont les évolutions possibles ?
Mon processeur est loin d’être parfait, le souci du VLIW c’est qu’on atteint vite ses limites théoriques. Dans mon cas, deux instructions par cycle, et ensuite ? On pourrait faire quatre ou huit instructions par cycle, mais comme dit plus haut ça ne servirait pas à grand-chose. Comme expliqué avant, de façon statique pour un CPU généraliste, quatre instructions serait « correct », mais resterait limité. On aurait des gains ici et là, mais probablement pas satisfaisants à mon avis. A huit ça augmenterait encore plus la complexité du processeur, pour des gains très minimes.
L’expérience de l’Itanium est pour moi intéressante, c’était un VLIW « évolué » qui pouvait fournir six instructions par cycle. Et pourtant, même comparé aux Intel 3xxx, par exemple, qui ne fournissaient pas un IPC très élevé en moyenne (autour de une ou deux instructions/cycle), l’Itanium ne faisait pas beaucoup mieux. Alors, certes il était très dépendant du compilateur, mais il montre que cette approche, de façon statique à six instructions par cycle, n’est pas satisfaisante parce que les gains ne sont pas « proportionnels » au nombre d’instructions par cycle.
C’est pour cela que je n’ai pas envie d’avoir la même approche (faire un VLIW 4/8 ou plus) et faire les mêmes erreurs.
Une autre idée est de gérer deux instructions de façon statique et les deux autres de façon dynamique. Il y a des cas (une boucle/condition) où il est un peu plus compliqué de gérer les instructions statiquement. Sauf si vous dépliez la boucle, mais là vous vous trouvez avec un gros dépliage.
Alors la version que je veux faire évoluer est ce qu’on peut appeler de l’EPIC. L’EPIC est un mélange entre VLIW et superscalaire.
Je veux intégrer aussi un « window » pour fenêtre d’exécution. Cela me permettrait de connaître à l’avance le code, et donc de le traiter plus facilement (et aussi que les boucles inconditionnelles soient gérées bien avant). Cela me permet plusieurs gains : une meilleure optimisation des boucles, monter plus facilement à trois ou quatre instructions par cycle, des caches miss et des blocages du processeur moins pénalisants, etc.
Bien sûr pour ce genre d’architecture tout est à « inventer », on ne peut pas trop s’inspirer d’un processeur existant vu le peu d’existant justement.
L’AltairX pourrait-il devenir un GPU ?
Alors j’avais prévu de faire un GPU aussi. Faute de temps, je n’ai pas eu le temps de m’en occuper. Disons que je privilégie un GPU relativement spécifique, un GPU qui ne serait qu’en lecture seule, et ne permettrait d’écrire que via le SPM ou un PPU (pour Pixel Process Unit). Le but étant que le fillrate (donc le remplissage de pixels) et le calcul soient en parallèle.
Le souci d’un GPU, c’est que c’est forcément « gros », du coup je réfléchis à faire une version plus « petite ». Une réflexion est de tout faire en float 16 bits, ça serait à tester ! Mais comme j’aimerais un GPU par défaut sur mon CPU, il faudrait un GPU petit mais assez puissant quand même.
Un autre point, je ne compte pas forcément le rendre « compatible » OpenGL. Le seul point que je tenterai de faire, c’est de le rendre compatible OpenGL 2 ES et Vulkan.
Quid du hardware autour ?
Un autre point qui me tient à cœur est aussi l’architecture autour du processeur sur laquelle je travaille, je trouve que cela est presque aussi important. J’ai toujours trouvé cela dommage qu’il n’y ait pas de machine à la fois « simple et efficace », en termes de hardware. Cela est rarement mis en avant vu que, en général, la programmation de driver est seulement faite par une poignée de personnes, et au pire on laisse cela à l’OS.
C’est aussi le gros souci à mon sens du PC x86 : si vous voulez faire un OS maison, en général tout est full CPU, pas possible d’utiliser un DMA, faire du son, utiliser le GPU… Personnellement, je trouve cela frustrant, moi qui code sur des vielles consoles où j’ai accès à tout cela. Aller sur une plateforme où rien de tout cela n’existe est aberrant… (Enfin si, ça existe, mais de façon trop complexe et peu documentée). D’ailleurs c’est un point rarement mis en avant, il manque une spécification de l’ensemble d’un ordinateur « normalisé » (et idéalement ouvert). Pour moi ce serait le top, c’est aussi pourquoi je crée ce processeur : pour avoir aussi une machine avec tout ce qui va « autour » au top et bien fichu.
Selon moi, les ordinateurs auraient dû suivre un peu les consoles : une nouvelle génération tous les 5-7 ans, en prenant compte des nouvelles avancées. Cela permettait que les devs puissent optimiser l’existant.
Une chose que je me suis toujours demandée : vu que les specs sont rarement ouvertes, exploite-t-on correctement le matériel ? Sur console, toutes les specs sont disponibles actuellement. Plus les gens échangent entre eux pour exploiter le matériel concerné, plus la machine révèle son plein potentiel.
Et je pense qu’avoir trop de matériels différents (comme sur PC) pousse beaucoup moins à l’optimisation (et je parle aussi des drivers, ça me semble évident que certaines cartes doivent être moins poussées que d’autres).
Est-ce que l’AltairX demande aussi de revoir la conception des couches plus hautes (compilateur, langage, OS) ?
Oui sur plusieurs niveaux :
Le compilateur forcément, parce qu’il a en charge une grosse partie de l’optimisation. Par défaut, le CPU n’en fait pas, il fait entièrement confiance au compilateur pour ça. De plus le compilateur devra aussi utiliser le SPM pour faire du Spilling (considérer de la mémoire comme des registres).
D’un point de vue programmation, si on veut optimiser le processeur il faudra utiliser le SPM : il existait une technique sur la PS2 et la PS3, qui était de faire un double buffering des données, le but est de précharger les données avant de les utiliser, cette technique ne marche forcément que sur des tableaux qu’on lit linéairement (ou d’un bloc dont on sait à l’avance qu’on va le lire).
Et c’est tout, j’ai tenté de coller au mieux mon ISA sur les contraintes des langages actuels.
Et puis les compilateurs actuels sont assez intelligents pour détecter des instructions SIMD, donc le besoin de faire de l’assembleur est un peu plus réduit.
Pour l’OS, il devra faire un gros taf sur le réordonnanceur, parce que je ne compte pas faire de cohérence de cache ! Donc les processus resteront sur leur core respectif. Si l’OS veut le changer il faudra vider le cache de ce core (c’est un peu long, mais s’il ne le fait qu’une fois par seconde, ça ira). L’OS a une partie du SPM à gérer, qui lui est dédiée pour ses propres optimisations ou communications entre les différents cores.
Comment pensez-vous fabriquer l’AltairX ? Est-ce vous travaillez avec des constructeurs ?
Alors tout d’abord il faut le faire fonctionner ! Il existe pour cela des cartes reprogrammables qu’on appelle FPGA. Vous pouvez concevoir n’importe quelle puce avec, c’est excellent pour du prototypage, pour déboguer, etc. Et, bien sûr pour le faire fonctionner en « vrai ».
Mais fonctionner à quelle vitesse ? Est-ce que « l’imitation est parfaite », ou alors y a-t-il tout de même des choses qu’on ne voit pas ?
Alors je n’ai pas terminé l’implémentation, donc je ne pourrai pas dire à quelle vitesse exactement. On peut viser raisonnablement du 100-200 MHz, mais tout dépend de la carte, et de l’implémentation qu’on y fait.
Pour les choses qu’on ne voit pas, malheureusement je ne pourrai pas dire, je n’ai jamais conçu de processeur avant.
Il faut savoir que même AMD utilise les FPGA pour prototyper. Mais ce qui est sûr, c’est que la gravure est bien plus complexe, surtout qu’il faut un PDK (Process Design Kit) pour pouvoir concevoir sa puce, sachant que chaque fondeur et chaque techno aura des différences. Ce travail n’est pas à faire sur FPGA.
J’utilise un Spartan 7, plus exactement le XC7S50. Je programme le FPGA avec VHDL. Il existe des outils open-source pour cela, comme GHDL (voir la dépêche de sortie en 2021) et GTKWave, qui permettent de voir vos signaux.
Ensuite quand tout cela est fait, on peut éventuellement penser à le graver. Chez efabless, vous pouvez le faire pour 10 000 $ avec une techno en 130 nm (soit un Pentium 4 !). C’est plus avancé que la PS2 ou la GameCube (180 nm).
Si on arrive aussi loin, je ferai sûrement une campagne de financement participatif avec kickstarter.
Pour la suite, c’est une bonne question. La fabrication de processeur coûte cher, est ce qu’une société serait prête à mettre de l’argent dessus ? Je ne crois pas. Si on essaye d’être plus « pragmatique », il faudrait qu’une entreprise existante en Europe le développe, donc STMicroelectronics, Infineon ou Imagination Technologies (voir NXP Semiconductors). Le mieux ça serait qu’il soit en France donc STM, mais on est champion dans la prise de risque donc… Pourtant je pense que c’est primordial qu’il existe un processeur européen.
Mais se pose la question de l’usage, non ? Car le processeur sans carte mère ne sert à rien. N’est-ce pas tout un écosystème à bâtir, ou pourrait-on commencer avec des petites cartes simples ?
Idéalement son usage serait un Raspberry Pi-like, mais je le verrais plus comme un mini-ordinateur, peu cher et accessible facilement. On est donc obligé de passer par des petites cartes dans un premier temps, pour que les développeurs se fassent la main dessus, et surtout parce que c’est le moins risqué financièrement.
Mais oui, il y a tout un écosystème à bâtir avec, ce qui veut dire que les outils de dév' doivent être faciles et accessibles à la fois.
Est-ce qu’il est prévu de mettre en place une association ou une fondation à terme pour piloter le projet, comme c’est déjà le cas pour RISC-V ou OpenPower ?
Non, je n’avais rien prévu de tel. Pas que je sois fermé à la question, mais une fondation suppose d’avoir des investissements privés, et je ne vois pas comment je pourrais les avoir.
Une association est plus que possible. Pour le moment c’est un peu trop tôt, mais ensuite pour pouvoir payer du matériel, ou pouvoir faire des petites cartes de dév', pourquoi pas, c’est une alternative plus « probable ».
Que souhaitez-vous dire aux lecteurs de LinuxFR en conclusion ?
Déjà merci d’avoir tout lu ! Je n’ai pas forcément tout expliqué en détail pour certaines choses, mais en tout cas je suis ravi de le faire découvrir au plus grand nombre. Ce processeur m’a beaucoup apporté en termes de connaissances, mais j’ai aussi appris, étrangement, qu’un tel processeur pourrait se démarquer sur le paysage actuel.
J’avais des connaissances de programmeur assembleur depuis dix ans ! Donc j’avais des connaissances assez avancées sur la micro-architecture. Mais lire des articles et concevoir un processeur, ce n’est plus trop la même chose. Il y a des trucs auxquels on ne s’intéresse pas forcément, comme les détails d’implémentation des caches, du fonctionnement de la RAM en interne, etc., mais aussi la fabrication d’un ISA, comment on implémente toutes les étapes d’une instruction. Mais par exemple, j’avais une idée assez vague des processeurs Out of order. Et puis ça permet au final de sortir de la « boite », de penser différemment quand on comprend « tout ».
Au final ce processeur, c’est la confirmation d’une intuition de départ. Je pensais qu’il apporterait quelque chose. Mais, vu l’utilisation actuelle de l’informatique, la plupart des personnes (moi y compris) souhaitent des machines de plus en plus petites, moins énergivores tout en gardant des performances acceptables. AltairX se prête bien à ce genre d’équilibre. L’autre point est qu’on est dans un petit rebond des architectures CPU, ARM et RISC-V qui viennent en force, alors que le x86 était seul depuis trop longtemps !
Ce qui m’a convaincu de me lancer sur ce processeur et qu’il ne reste pas une idée vague, c’est que je voulais avoir les mêmes optimisations sur PC que sur ma PS2 (principalement, celle pour éviter les caches miss et le contrôle total du nombre de cycles). L’autre point, ce sont les failles meltdown et spectre qui m’ont fait penser qu’il faudrait vraiment un processeur avec une technologie différente qui éviterait ce genre de faille (l’exécution spéculative), tout en apportant un vrai plus technologique. Mon premier jet était donc presque une copie conforme de l’Emotion Engine avec des briques du CELL dessus.
Pour finir je voudrais dire que c’est un projet open source, donc si vous avez des compétences et pas forcément calé en hardware, il y a du travail à faire sur le compilateur, sur un portage Linux et d’autres choses très amusantes ! 🙂
