AltairX : le processeur du futur ?

Posté par devnewton 🍺 (site web personnel) le 21 juin 2023 à 23:13. Édité par orfenor, Kannagichan, dyno partouzeur du centre, L'intendant zonard, Yves Bourguignon, jseb, Nicolas Boulay, palm123, Ysabeau 🧶, Nils Ratusznik, bobble bubble, vincent LECOQ, volts, SpaceFox et Arkem. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

juin

2023

Kannagi, récemment interrogé sur son SDK pour Neo Geo, travaille sur un nouveau concept de processeur : l’AltairX a pour but de concilier au maximum coût, facilité de conception et performance.

C’est un processeur VLIW, ce qui veut dire que c’est le compilateur qui a en charge une bonne partie de l’optimisation, ce qui permet une conception plus facile avec moins de transistors qu’un processeur classique.

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 statique¹ 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.

Decode de l’AltairX

ISA de l’AltairX

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.

Cache et Bus de l’AltairX

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.

Pipeline de l’AltairX

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.

GPU de l’AltairX

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 ».

Die de l’AltairX

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.

PCB de l'AltairX

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 ! 🙂

de manière statique il ne s’agit pas ici de poser un terme technique, mais d’indiquer un processeur in order, contrairement au processeur out of order consideré comme dynamique. ↩

Aller plus loin

Le dépôt de Kannagi (163 clics)

# Merci

Posté par antistress (site web personnel) le 22 juin 2023 à 01:30. Évalué à 8.

Merci, c'est passionnant.

Par contre autant tout est très détaillé, autant quand on arrive à :

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.

on passe de suite à autre chose.

Serait-ce possible d'en savoir plus à ce sujet ?
- [^] # Re: Merci
  
  Posté par Arkem le 22 juin 2023 à 07:53. Évalué à 3.
  
  À défaut, j'en ai fait un lien vers la page Wikipédia
  - [^] # Re: Merci
    
    Posté par antistress (site web personnel) le 22 juin 2023 à 09:43. Évalué à 3.
    
    Ha oui !
- [^] # Re: Merci
  
  Posté par Kannagichan le 22 juin 2023 à 09:40. Évalué à 5.
  
  C'est un peu compliqué,je l'explique un peu ma vision, mais grosso modo, j'aimerais faire un bufferqui stocke les instructions qui ne peuvent pas être exécuter tout de suite, comme ça on peut aller plus loin et exécuter les instructions à l'avance.
  
  C'est assez empirique , mais comme l'AltairX actuelle peut traiter relativement facilement 1-2 instructions/cycle.
  
  Donc le but c'est d’exécuter immédiatement les instruction à porté ,et exécuter les instructions plus loin en parallèle pour augmenter ILP.
  
  Le truc c'est que je travaille sur algorithme et l'implémentation pour faire cela, je taff donc pour le moment avec un papier et un stylo pour avoir une vision plus précise pour faire ça.
  
  Pour cela que j’en dit pas forcément plus , parce que je l'ai pas mis en place et que ce n'est pas finalisé, mais j'ai des brouillons et des idées, mais je veux que tout soit bien fait, donc je prend mon temps.
  - [^] # Re: Merci
    
    Posté par antistress (site web personnel) le 22 juin 2023 à 09:44. Évalué à 4.
    
    OK, merci !
  - [^] # Re: Merci
    
    Posté par orfenor le 22 juin 2023 à 09:46. Évalué à 10.
    
    Faut préciser aussi que lors de la rédaction Kannagi a essayé «de ne pas faire un livre», tant il y avait de choses à dire et d'explications possibles à rajouter. C'est un domaine d'étude à part entière. On a essayé de rester concis et précis pour qu'avec un peu de recherches et de réflexions vous puissiez comprendre. Devnewton a créé la page CPU dans le wiki à partir de morceaux de l'article qui devenait trop long. Il faut absolument lire cette page.
    - [^] # Re: Merci
      
      Posté par antistress (site web personnel) le 23 juin 2023 à 11:16. Évalué à 5. Dernière modification le 23 juin 2023 à 11:16.
      
      Top la page CPU du Wiki, merci !
  - [^] # Re: Merci
    
    Posté par Nicolas Boulay (site web personnel) le 22 juin 2023 à 13:18. Évalué à 9.
    
    Cela s'appelle du scoreboarding : https://en.m.wikipedia.org/wiki/Scoreboarding
    
    "La première sécurité est la liberté"
  - [^] # Re: Merci
    
    Posté par YBoy360 (site web personnel) le 23 juin 2023 à 06:16. Évalué à 4. Dernière modification le 23 juin 2023 à 06:17.
    Donc le but c'est d’exécuter immédiatement les instruction à porté ,et exécuter les instructions plus loin en parallèle pour augmenter ILP.
    
    Dans une vie antérieure, j'avais un collègue faisant de l'optimisation CPU sur Itanium (un processeur VLIW d'HP, conjointement créé en collaboration avec Intel).
    
    Le but de cette architecture était, selon ma compréhension, d'éviter les branchements non prévisibles pour avoir un pipeline + grand (et donc plus simple, et pouvant monter en fréquence plus facilement).
    
    Le(s) problème(s) de cette architecture (outre l'incompétence d'Intel pour le design de CPU performant à cette époque) :
    - Cache d'instructions doit être énorme pour alimenter le pipeline (je parle des instructions, pas des données);
    - Compilateur compliqué..
    Le problème, comme bien souvent, c'est que l'optimisme et les promesses d'un concept ne sont pas toujours observables dans le monde réel. Cela dit, si le code est concis, ce concept peut-être intéressant. Mais c'est une contrainte qui disqualifie totalement ce concept.. Les conditions aux limites, comme disent les physiciens.
    - [^] # Re: Merci
      
      Posté par orfenor le 23 juin 2023 à 10:54. Évalué à 4.
      
      L'Itanium est un sujet qui revient beaucoup, dans les commentaires et dans l'article (et dans le chat de rédaction pendant l'écriture !). Kannagi a déjà répondu un peu plus bas et dans l'article
      
      Je cite un morceau de sa réponse
      
      Oui l'erreur de l'Itanium est la complexité de faire un compilo performant avec, mais je pense qu'il a brûler trop d'étape, il est parti direct avec 6 instructions/cycles ce qui est énorme, et surtout compliqué à optimiser.
  - [^] # Re: Merci
    
    Posté par zerodeux (site web personnel) le 23 juin 2023 à 11:47. Évalué à 4.
    
    Donc le but c'est d’exécuter immédiatement les instruction à porté ,et exécuter les instructions plus loin en parallèle pour augmenter ILP.
    
    C'est pas de l'exécution spéculative qui pourrait typiquement mener un à un SPECTRE/MELTDOWN ? Sur ce sujet je retiens que jouer avec le temps (réordonner, anticiper) est un risque non négligeable.
    
    Ce n'est a priori pas ton but, mais je vois aussi une opportunité de rester sur un processeur à l'architecture "simple" (au sens "un expert peut raisonner sur son modèle sans se fourvoyer", pas en opposition avec "sophistiqué") et donc faisant passer la sécurité en premier - et ça semblerait compatible avec le but d'efficience. Parce qu'aujourd'hui n'importe quel CPU/SoC ARM/RISC/CISC ne rassure personne en termes de sécurité tellement ils sont complexes (on en est quand même à mettre des CPUs dans les CPUs…)
    - [^] # Re: Merci
      
      Posté par Kannagichan le 24 juin 2023 à 10:33. Évalué à 2.
      
      Oui je suis d'accord actuellement l'AltairX n'a pas de faille MeltDown/Spectre.
      
      L'évolution que je voulais mettre n'est pas de l’exécution spéculative, mais surtout que de pouvoir prefetch plus facilement et que le processeur se bloque pas systématique sur un cache miss (qu'il doit du i-cache ou d-cache).
      
      Et c'est là toute la difficulté c'est que je veux faire ça sans faire de l'OoO.
      
      Et surtout je voulais faire un léger réordonnanceur pour les cas plus "compliqué" a gérer, mais loin d’être un truc complexe.
      
      De toute façon de base s'il doit sortir, ça serait dans sa version simplifié dans un premier temps.
# Champ de taille des opérations dans les instructions?

Posté par Joël le 22 juin 2023 à 01:32. Évalué à 6.

Je serais curieux de mieux comprendre le raisonnement derrière ce champ de taille des opérations dans les instructions.

Je comprends l’intérêt pour les opérations mémoires (par exemple dans MIPS, lw --load word-- n'est pas pareil que lb --load byte) mais pas trop pour les opérations arithmétiques ou logiques (par exemple dans MIPS, add additionne deux registres peu importe la taille des données effectives).

Si ce champ de taille était intégré à l'opcode (comme ça l'est pour la plupart des ISAs je crois), ça multiplierait le nombre d'instructions possible par quatre. Donc Kannagi se tirerait moins les cheveux :)
- [^] # Re: Champ de taille des opérations dans les instructions?
  
  Posté par Kannagichan le 22 juin 2023 à 09:32. Évalué à 5. Dernière modification le 22 juin 2023 à 09:33.
  
  Le raisonnement est tout simplement la gestion des conversions,je m'explique.
  
  Admettons qu'on fait des calcul en 8 bits (c'est relativement courant).
  Si on fait 0xFF + 0x2 cela fait 0x101 , mais cela devrait faire 0x01 non ?
  Ce que fait le MIPS (et RISC-V) c'est de faire un AND ensuite , si on renvoie cette valeur en int32 par exemple.
  
  Du coup pour éviter de mettre des AND a chaque conversion de type, j'ai mis cette solution.
  
  Pareil pour les décalage binaires, si on fait 0xFF+ 0x2 ça fait 0x101 , si on décale à droite, on fait quoi ? 0x80 ? alors que ça devrait faire zero. (toujours en 8 bits)
  Du coup a part encore faire un AND…
  
  On espérant que j'ai répondu pourquoi à ce choix "étrange" :)
  - [^] # Re: Champ de taille des opérations dans les instructions?
    
    Posté par Joël le 22 juin 2023 à 18:15. Évalué à 3.
    
    Intéressant. J'avais jamais fait gaffe que le code contenait plein de AND pour tronquer les résultats.
    
    Cela dit, est-ce que absolument toutes les instructions ont besoin de ce champ de taille ?
    
    Si c'est pas de le cas, ça vaudrait quand même le coup de l’intégrer à l'opcode pour libérer de la place, autrement tu te retrouve avec 2 bits gâchés au moins de temps en temps.
# Ok, le hardware pourrait être fait, mais le software ?

Posté par xryl669 le 22 juin 2023 à 09:11. Évalué à 10. Dernière modification le 22 juin 2023 à 09:11.

J'ai beaucoup de mal avec une nouvelle architecture "exotique", aussi bien soit elle. Car faire tourner une nouvelle ISA sur un FPGA, j'ai un peu l'impression que c'est facile (Leon, Microblaze, Pico8/32, RISC-V).

Le problème, paradoxalement, c'est pas le hard du CPU, c'est le hard complet (avec les devices, type bus SPI pour la flash du boot, PCIe, USB, etc…) et évidemment le soft.

Le soft, c'est réussir à faire intégrer le générateur de code pour l'architecture dans GCC et/ou LLVM (chose qui est déjà très compliquée à réaliser, ça ne s'écrit pas avec le dos d'une cuillère), mais s'assurer que ça fonctionne avec tous les paquets nécessaires pour un OS.

Un raspberry-pi like, c'est avoir un CPU avec tous les périphériques nécessaires à booter linux (c'est à dire flash NOR ou SPI + gestionnaire d'interruption + MMU complexe + DMA + …), mais également tous les périphériques nécessaires à l'OS (sortie vidéo, réseau, IO pour l'IHM, powersaving, encodage et décodage video, GPU, etc…) et pouvoir compiler, sans erreur, tous les paquets d'une distribution type debian (donc avec du C/C++, mais aussi du Java, du Rust, du Go, … autant de compilateur à implémenter).

Déjà, avec le tsunami RISC-V, c'est pas gagné, alors avec une ISA toute neuve sans une masse d'implémentation, je pense que c'est mort…

À la limite, une carte type "Arduino" avec un microcontrolleur sans OS, pourquoi pas. Mais même dans ce cas, tous les périphériques d'un microcontrolleur sont à implémenter, et c'est pas un Freecore qui va fournir cette implémentation.
- [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
  
  Posté par Kannagichan le 22 juin 2023 à 09:49. Évalué à 10.
  
  Tu as totalement raison.
  Et pour être honnête c'est peut être ça, qui a fait que l'idée de mon processeur est resté dans ma tête durant des années sans jamais en parler ni le publier !
  
  Ce qui me chagrine sur ton post ,c'est que ce n'est pas un processeur fait totalement pour le fun.
  l'AltairX tente de résoudre un problème :
  Le premier proposer des solutions pour abaisser les caches miss.
  
  Le second proposer un processeur haute performante sans aller sur du SuperScalaire Out of Order, ce point est très important parce que le OoO, c'est un peu le boss final, soit on se dit que c'est la seule solution, et donc on se retrouvera toujours avec les mêmes leaders et aussi avec des processeurs qui chauffe beaucoup/consomme beaucoup/coûte cher.
  
  Soit on arrive à proposer une architecture suffisamment bien pensé pour que le compilateur fasse le gros taff et donc allège le hardware et réduit sa consommation.
  
  Et pour avoir la réponse, pas le choix faut mettre les mains dedans, je suis conscient que y'a beaucoup de chance que cela n'ira pas plus loin qu'un FPGA et au mieux une petite carte avec 2/3 entré/sortie.
  - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
    
    Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 22 juin 2023 à 11:41. Évalué à 4.
    
    À propos du compilateur qui ferait le gros du taff, ce point n'aurait-il pas justement contribué à tuer l'Itanium ? Pensez-vous que les compilateurs ont fait désormais suffisamment de progrès (certains journaux sur de l'optimisation de code C++ ici laissent entendre le contraire) ? Comptez-vous sur des avancées prochaines dans le domaine ? Par exemple à base d'IA ? après tout optimiser du code, c'est un jeu relativement simple.
    
    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
    - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
      
      Posté par Kannagichan le 22 juin 2023 à 12:36. Évalué à 3.
      
      Je trouve que l'article est incomplet,il dit que les compilateurs sont pas assez performant parce qu'ils savent pas déplier une boucle.
      
      Alors les compilateurs savent déplier une boucle mais je pense que cette optimisation à été fortement réduite, parce que cela augmente énormément la taille du binaire pour des gains relativement faible dans beaucoup de cas,un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.
      
      D'ailleurs son code C est tronqué ,quand il deplis il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?
      
      Il sait pas du coup s'il doit déplier 8 fois, il va devoir générer beaucoup plus de code au cas où ça serait 10, ou 3, c'est pas des multiples de 8 mais il doit gérer ces cas là.
      
      Bref juste pour dire que oui les compilateurs actuelles sont relativement bon, et donc je considère qu'ils ont fait fait désormais suffisamment de progrès pour qu'on puisse lui donner plus de taches.
      
      Oui l'erreur de l'Itanium est la complexité de faire un compilo performant avec, mais je pense qu'il a brûler trop d'étape, il est parti direct avec 6 instructions/cycles ce qui est énorme, et surtout compliqué à optimiser.
      
      Du coup les gains devait être minime, vu que forcément le I-cache devait pas mal souffrir et que l'IPC devait tourner autour de 2.
      - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
        
        Posté par xryl669 le 22 juin 2023 à 14:20. Évalué à 2.
        
        un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.
        
        D'ailleurs son code C est tronqué ,quand il deplit il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?
        
        Beh si, il sait justement. Le loop unrolling, c'est pas fait sur le compteur de boucle for i = O; i < N; i++), mais sur le nombre d'ALU disponible sur le CPU, on le nombre d'exécution qui peuvent se faire en parallèle (SIMD). À la limite, il peut aussi déplier sur la taille du cache et du prefetcher (si la boucle touche une zone de 16 octets, il va déplier suffisamment pour les 4 itérations rentrent dans une ligne de caches de 64 octets).
        
        De toute façon, le compilateur va convertir ton code en une sorte d'arbre logique des opérations à effectuer sur les données, et le backend va essayer de mapper ces opérations le mieux possible sur l'architecture binaire cible. Et le gros problème, c'est justement de décrire cette architecture cible en étant le plus efficace (et juste!) possible.
        
        L'itanium est arrivé trop tôt et le soft était pas prêt à utiliser cette architecture. Les algorithmes SIMD/vectorisés sont arrivés des années plus tard.
        
        De plus, c'est quasi impossible de faire un processeur efficace avec de multiples instructions/cycle sans avoir de out of order ou au moins une sorte de microcode. Les dépendances sont simplement insolvables sans résoudre l'ordre d'accès aux données (sequential memory access synchronization) sur un vecteur de plusieurs opérations, ce que le compilateur ne fourni pas (sauf en C++ pour les atomiques, mais c'est tout).
        Donc, au niveau du processeur, si tu as la séquence de code:
        A = B B++ C = D D = B A += C
        Bien que toutes ces opérations soient indépendantes les unes des autres (sauf la dernière), le processeur ne peut pas faire A = B en même temps que B++ car l'accès et le stockage à B doit être synchronisé sur ses ALU. Avec le OutOfOrder, il peut réordonner (A=B, C=D) et (B++, D=B) s'il le veut et s'affranchir de la synchronisation des caches pour saturer ses unités d'exécution.
        
        Le compilateur ne peut pas changer l'ordre non plus (à la limite le C=D peut remonter) car le D=B a un effet observable donc B doit être calculé. Je ne parle même pas des atomiques/volatiles.
        
        Ici avec 2 unités d'exécutions, tu ne peux pas faire moins que 4 cycles (A = B, puis B++, puis (C=D, D=B), puis A+=C) sans OoO, vue les dépendances.
        
        Je parle ici de l'aspect implémentation et pas mathématique évidemment.
        
        [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
        
        Posté par Kannagichan le 22 juin 2023 à 15:04. Évalué à 4. Dernière modification le 22 juin 2023 à 15:05.
        
        Oui, pour ça que je fais pas pas plus que 2 instructions/cycles
        
        Sinon pour ton code, c'est un peu faux, on peut le faire sur 3 cycles (et ça demande pas une grosse implémentation):
        A = B E = B
        C = D E++
        A += C D = E
        
        Et je ne pense pas qu'un OoO fasse mieux ici, pour moi l'avantage d'un OoO est ailleurs.
        Elle est sur son exécution spéculative (qui du coup permet un meilleur ILP), sur ces prefetch, sur pouvoir continuer a exécuter du code malgré un cache miss.
        
        Sinon pour le reste un OoO n'apporte pas grand chose comparé à un in order (si le compilo fait son taff).
        
        Alors je ne pense pas que tout faire statiquement soit la solution, pour cela que je voudrais améliorer mon proc pour gérer les 3 cas en haut (de façon différente , mais de le gérer quand même).
  - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
    
    Posté par antistress (site web personnel) le 24 juin 2023 à 12:16. Évalué à 3.
    
    Pour comprendre, le superscalaire c'est le fonctionnement des instructions MMX et SSE en x86 ?
    - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
      
      Posté par Kannagichan le 24 juin 2023 à 14:14. Évalué à 3.
      
      Non rien n'a voir ,MMX et SSE sont des instructions SIMD.
      Superscalaire ,c'est quand tu exécute plusieurs instructions, mais qui n'est pas spécifié par le compilateur.
      VLIW c'est le contraire, tu exécute plusieurs instructions spécifié par le compilateur.
      
      Le mélange des deux, c'est surtout pour gérer plusieurs cas, faudrait que j'écris des cas concret pour voir quel problématique je tente de résoudre.
      - [^] # Re: Ok, le hardware pourrait être fait, mais le software ?
        
        Posté par antistress (site web personnel) le 24 juin 2023 à 14:40. Évalué à 4.
        
        Merki
# Petit, peu de consommation, fortement multi-coeur?

Posté par alpha_one_x86 (site web personnel) le 22 juin 2023 à 14:06. Évalué à 5.

Avec les points suivant: Petit, peu de consommation
Ca me fait penser fortement la une base idéale pour faire un CPU fortement multi-coeur (>64 coeurs), mais c'est vrai que la cohérence de cache serai un plus pour cette usage.

Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Débouchés?

Posté par lym le 22 juin 2023 à 16:59. Évalué à 9.

Sacré projet, mais à mon sens irréalisable seul et il serait sans doute intéressant d'avoir au niveau des débouchés l'approche originale de sa définition.

Car certains débouchés sont inaccessibles à bien des processeurs modernes, par manque de déterminisme ou car ils sont pétris d'états indéfinis:

De ce point de vue, le PowerPC (même si, au milieu des derniers SoC Freescale/NXP, le coreNet gênait déjà un peu car son fonctionnement sans aucun contrôle/réglage tenait du secret d'état, contrairement a l'architecture de bus interne antérieure permettant de gérer très classiquement des priorités entre périfs et un parking-master) tombant en désuétude après une vingtaine d'années de développement et déverminage de ses itérations successives par l'industrie Télécoms laisse un vide pour les futures applications critiques (avionique en particulier).

Ce n'est pas encore trop visible, avec des délais de développement/certification dépassant 10 ans, mais c'est un problème qui inquiétait déjà il y a 4 ou 5 ans et même si je n'ai plus d'infos récentes, pourrait commencer à faire vraiment suer dans certains bureaux d'étude: Assez pour les motiver à étudier des approches différentes combinant potentiellement simplicité et performance?

C'est clairement un domaine ou on préférera voir un maximum d'optimisations gérées de manière visible par le compilo que de manière obscure dans le silicium.
- [^] # Re: Débouchés?
  
  Posté par Kannagichan le 24 juin 2023 à 10:26. Évalué à 4.
  
  Merci pour ton commentaire.
  
  Effectivement une solution serait de le proposer à des acteurs qui en ont besoin, que au grand public où on serait directement mis en concurrence avec le x86/ARM/RISC-V !
  
  Le truc c'est à qui s'adresser ?
# maquettage ou prototype

Posté par Selso (site web personnel) le 23 juin 2023 à 20:45. Évalué à 4.

Hello,

Déjà avoir quelque chose sur FPGA qui fonctionne sera génial. Mais est-ce que ce prototype sur FPGA donnera une bonne vision du potentiel de ces choix d'architecture ?
Est-ce qu'on pourra lui donner une comparaison plausible si on le produisait avec une gravure équivalente aux puces du marché ?
Merci pour le partage dans tous les cas.
- [^] # Re: maquettage ou prototype
  
  Posté par Kannagichan le 24 juin 2023 à 10:27. Évalué à 2.
  
  Si tu le met sur FPGA, tu peux donc le test et voir ces performance réels
  
  Donc un prototype sur FPGA donne une idée oui de ce que ça donnerai,surtout si il entre sur un FPGA grand public.
# "Palette d'instruction": solution au nombre limité d'instructions?

Posté par De_passage le 23 juin 2023 à 23:52. Évalué à 3.

Salut. Ce message est mon premier sur ce site que je fréquente depuis un moment, je me suis inscrit seulement maintenant pour commenter cette dépêche.

Je ne suis pas un expert dans le domaine de l'architecture de processeur et de la micro-électronique en général, donc les termes que je vais utiliser risquent de ne pas être très précis.

Si je résume, ce processeur a d'un côté une limitation du nombre d'instructions qui peuvent être implémentées à cause du nombre limité de bits disponible pour leur identifiant, et de l'autre pour chaque coeur une mémoire de 32Ko (la SPM) dans laquelle on peut manuellement stocker des données directement ou en passant par le DMA.

Du coup, pourquoi ne pas créer une sorte de "palette d'instructions", fonctionnant de la même manière que les palettes de couleurs pour les anciennes consoles de jeu vidéo, qui serait stockée dans cette mémoire de 32Ko?

L'avantage principal des palettes de couleur est justement de pouvoir les représenter de manière plus compacte dans une image, en échange d'une limitation des couleurs disponible pour l'image à celles présentes dans la palette (exemple: une palette de 256 couleurs codées en 32-bits, permettant de représenter la couleur de chaque pixel d'une image donnée avec une valeur codée sur 8 bits).

Ici, l'idée serait la même, puisque les 7 bits de l'opcode actuel ne serviraient plus à représenter directement une instruction réelle, mais serait un pointeur vers l'identifiant de cette même instruction, stocké dans la palette et codé sur un plus grand nombre de bits.

Ainsi, si ces identifiants ont par exemple une taille de 16-bits, on pourrait représenter au total plus de 32'000 instructions, mais seules 128 d'entre-elles seraient utilisables directement par chaque coeur car stockées dans cette palette d'une taille de 256 octets.

Il faudrait donc, si c'est nécessaire, pouvoir changer les valeurs dans la palette en fonction des instructions nécessaires à l'exécution des différents programmes.
Cela pourrait se faire en modifiant directement les différentes entrées de la palette.
Il serait également possible de créer plusieurs palettes (par exemple, 4 palettes de 32 instructions chacune), avec les différentes instructions qui y seraient réparties en fonction de la fréquence de leur utilisation, et ainsi remplacer complètement la palette des instructions les moins fréquentes par une autre palette.

Dans tous les cas, ce serait au compilateur de gérer en amont la création et le chargement de ces palettes. Et il faudrait une instruction spéciale permettant au coeur processeur de savoir combien de palettes existent pour pouvoir y accéder en interprétant correctement l'ancien opcode de 7 bits (premiers bits pour la palette, derniers pour l'instruction dans la palette).

Que pensez vous de cette idée? Est-ce qu'elle serait facilement implémentable?
Est-ce que le cache SPM peut utilisé comme une "palette RAM" avec 256 octets réservé d'office, ou bien faut-il créer une mémoire cache supplémentaire dédiée?
- [^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
  
  Posté par Kannagichan le 24 juin 2023 à 10:18. Évalué à 2.
  
  Cela serait trop complexe pour le compilateur,et on aurait une latence supplémentaire sur le fetch.
  
  Je connais d'ailleurs très bien les palettes de couleurs pour les anciennes consoles parce que je code sur SNES en assembleur et j'ai fait aussi un SDK pour la Neo Geo.
  (Mais je code aussi sur PS2 qui elle utilise encore des palette de couleurs).
  
  L'idée qu'on m'avait dite était enfaîte que je ferait un ISA 64 bits pour les instruction plus rare ! :)
  
  Solution plus simple et moins contraignante ! :D
  - [^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
    
    Posté par Tb_ le 02 juillet 2023 à 13:06. Évalué à 2.
    
    Cela serait trop complexe pour le compilateur,et on aurait une latence supplémentaire sur le fetch.
    
    Je m’interroge : pourquoi la gestion d'un set d'instruction par le compilateur serait trop complexe et la gestion d'un SPM serait acceptable ?
    Certain processeur populaire ont des tailles d'instruction variable…
    
    De quel latence parle-t-on ici ?
    
    Le raisonnement est tout simplement la gestion des conversions,je m'explique.
    
    Admettons qu'on fait des calcul en 8 bits (c'est relativement courant).
    Si on fait 0xFF + 0x2 cela fait 0x101 , mais cela devrait faire 0x01 non ?
    Ce que fait le MIPS (et RISC-V) c'est de faire un AND ensuite , si on renvoie cette valeur en int32 par exemple.
    
    Du coup pour éviter de mettre des AND a chaque conversion de type, j'ai mis cette solution.
    
    Pareil pour les décalage binaires, si on fait 0xFF+ 0x2 ça fait 0x101 , si on décale à droite, on fait quoi ? 0x80 ? alors que ça devrait faire zero. (toujours en 8 bits)
    Du coup a part encore faire un AND…
    
    On espérant que j'ai répondu pourquoi à ce choix "étrange" :)
    
    C'est une histoire de compromis : selon ce que peut faire le hardware et si la toolset sait l'exploiter : il n'y a pas forcement d’opération logiciel AND à faire :
    Effectivement si la taille des operateurs fait 32bits, le résulat en sortie de l'ALU de l'opération 0x0000_00FF + 0x0000_0002 sera 0x0000_0101, mais un décodage sur l'étage write_back de "store_byte", seule le mot de poids faible pourrait être repris. Cela induit automatiquement un AND, mais sans que l'opération n'apparaisse explicitement dans la liste des instructions.
    Ne pas avoir cette capacité de load et store de mot de 8 bytes au contraire induit l'introduction d'instruction logiciel logique supplémentaire.
    
    C'est toute la démarche compliquer de devinette qui consiste à comprendre et anticiper les caractéristiques des problèmes que la machine se destine à résoudre. Si la machine est destiné à traiter des échantillons sonore sur 24 bits (On parlait de DSP, Ahma quand le silicium coûtait cher ^{^)…} sans doute que les occurrences d’exécuter des instructions store et load 8bytes sont anecdotique. Par-contre pour un processeur destiner à manipuler un framebuffer dont les couleurs sont représentés par 3 composantes de 8bits, j'aurais quelques doutes.
    - [^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
      
      Posté par Kannagichan le 04 juillet 2023 à 20:05. Évalué à 1. Dernière modification le 04 juillet 2023 à 20:05.
      
      je ne vais pas répondre à ta deuxieme partie, parce que je suis d'accord avec toi.
      
      Je répond au premier parce que tu semble pas avoir compris la solution qu'on m'a proposé.
      
      On gros on me demande de faire une palette d'instruction.
      
      Donc déjà une palette demande deux fetch, un pour lire l'index et le suivant le SPM.
      Et cela pour compresser les instructions, l'idée n'est pas "idiote", mais mon intuition me dit que c'est une mauvaise idée, je doute qu'on trouve des pattern très semblable.
      
      (et perso un compilateur est déjà compliqué à faire , j'ai pas forcément le temps de tester cette idée :p ).
      - [^] # Re: "Palette d'instruction": solution au nombre limité d'instructions?
        
        Posté par Tb_ le 04 juillet 2023 à 23:48. Évalué à 1.
        
        Oui effectivement l'utilisation de SPM pour stocker une variation d’instruction set parait sous optimal. Je n'avais pas bien lu… l'analogie avec une palette de couleur est allé un peut trop loin :)
        
        Parcontre les méthodes utilisant une ou plusieurs instructions pour choisir entre plusieurs variations d'instructions set façon thumb mode du ARMv7 sont tout à fait valable pour adapter l'instruction set à certain traitement.
# F-CPU

Posté par Sytoka Modon (site web personnel) le 24 juin 2023 à 19:49. Évalué à 8.

Cela me rappelle l'aventure du F-CPU qui me semblait plus communautaire https://linuxfr.org/news/le-retour-de-f-cpu-le-processeur-libre

Personnellement, on j'aimais bien l'aventure des processeurs FORTH de Charles H. Moore https://en.wikipedia.org/wiki/Charles_H._Moore. Il essayait une autre voie, je trouvais cela amusant.
# ISA belle a les yeux bleux, les yeux bleux ISA bella

Posté par Tb_ le 02 juillet 2023 à 13:20. Évalué à 2.

pour moi l’ISA doit représenter en partie le fonctionnement interne du processeur.

Oui et non; Selon moi c'est plutôt le contrat entre la personne qui propose une machine et l'utilisateur de premier niveau (qui va produire du code assembleur, peu importe le moyen).
Par exemple ce qui se passe avec "l'ouverture" des ISA :RISC-V, openSparc etc … on va pouvoir assurer un minimum de fonctionnement et de connaissance commune assurant une compatibilité "basic" avec des toolset au bénefice d'un client qui pourra avoir une interopérabilité de vendeur pour une même ISA dans la limite de la fonctionnalité "basic".

Néanmoins chaque vendeur peut décider d’implémenter son processeur à 500Mhz ou 800Mhz sur un pipeline plus ou moins important, avec des opérateurs hardware ou non, des instructions plus ou moins spécialisé qui nécessiteront bien évidement une spécialisation vendeur de la toolsuite qui permettrons d'exploiter ces spécialisations aux mieux. (Cela inclu les caches, MMU, FPU et autres accélérateurs exotique)

La où pour un projet qui vise à permettre de gagner sa vie, on va sans doute chercher à combiné réduction des risques et maximiser les bénéfices: partir d'une ISA et d'un eco-system existant est un avantage important autant là je suis un peu septique sur la démarche. Je ne la comprends pas bien :
- c'est un processeur "generaliste" ou "specialisé", si oui sur quel traitement ? Les processeurs de console étaient des processeurs spécialisés et perdent de plus en plus cette caractéristique dans la mesure ou il y a une convergence vers d'autres équipements (lecteur DVD, home cinéma, navigation internet …) et que les PC incluent toujours plus d'accelerateur en tout genre (compression/décompression video, traitement d'image camera, accelerateur graphique). Il me semble que la Xbox et les denières génération de PS sont des PC maquillé, non ?
- C'est un processeur à but didactique ou une brute de guerre qui vise à péter des scores coreMark, l'efficacité énergétique, une surface réduite, un coût ?

A la lecture de l'article, les compromis choisis ne sont pas toujours claire pour moi.

Mais après tout : Ils ne savaient pas que c'était impossible … alors ils l'ont fait! :)
- [^] # Re: ISA belle a les yeux bleux, les yeux bleux ISA bella
  
  Posté par Kannagichan le 04 juillet 2023 à 20:07. Évalué à 3.
  
  Merci pour ton commentaire.
  
  Pour te répondre ,c'est un processeur généralise où son but est de réduire la surface,donc le coût tout en ayant de bonne performance, en gros de garder une bonne radio perf/prix/simplicité.
  - [^] # Re: ISA belle a les yeux bleux, les yeux bleux ISA bella
    
    Posté par sylgre le 13 juillet 2023 à 10:01. Évalué à 2.
    
    Bonjour,
    
    tu dis vouloir faire un processeur généraliste et vouloir garder un bon ratio perf/prix/simplicité.
    
    Les ennuis vont commencer quand il s'agira de quantifier ton architecture et de publier…
    
    Qu'est-ce qu'un processeur généraliste ? Desktop, serveur, embarqué ? Quel est ton appli cible ?
    
    Comment quantifier la perf ? Quel est par exemple le bon compromis entre vitesse et conso ?
    Comment mesurer/prévoir la conso ?
    
    Le prix : de quoi parle-t-on ? ASIC ? Quelle techno ? Quel fondeur ? Quel volume ?
    
    Simplicité : quelle est la mesure ? Un compilo pour EPIC ou VLIW n'est pas simple. L'expérience montre que ça complique l'utilisation et la diffusion de l'architecture car un même binaire ne peut pas suivre l'évolution de la plateforme.
    
    Bref, c'est un travail de titan et la plupart des « gros » y travaillent depuis longtemps : ST, ARM, Intel/AMD, IBM, Xilinx/Altera(intel).
    
    Évidemment, chacun a une réponse propre, selon son appli, sa techno, ses volumes.
    
    Quoi qu'il en soit, c'est un domaine d'étude très intéressant. Créer son ISA, implémenter son processeur et coder un compilateur (a minima un assembleur) est une expérience on-ne-peut-plus enrichissante et satisfaisante.
    - [^] # Re: ISA belle a les yeux bleux, les yeux bleux ISA bella
      
      Posté par lepton.phlb le 13 juillet 2023 à 19:33. Évalué à 2.
      
      Il y eu l'expérience Transmeta:
      Transmeta-Crusoe

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Sommaire

Préambule

Présentation de l’AltairX

Approche de ce CPU

Genèse

L’ISA de l’AltairX

Les caches de l’AltairX

L’architecture de l’AltairX

Quelques CPU remarquables qui ont inspiré l’AltairX

Interview de Kannagi

Pourquoi un nouveau CPU et pas le RISC-V ?

Quelles sont les évolutions possibles ?

L’AltairX pourrait-il devenir un GPU ?

Quid du hardware autour ?

Est-ce que l’AltairX demande aussi de revoir la conception des couches plus hautes (compilateur, langage, OS) ?

Comment pensez-vous fabriquer l’AltairX ? Est-ce vous travaillez avec des constructeurs ?

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 ?

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 ?

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 ?

Que souhaitez-vous dire aux lecteurs de LinuxFR en conclusion ?