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.
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! :)
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 Tb_ . En réponse à la dépêche AltairX : le processeur du futur ?. É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.
# ISA belle a les yeux bleux, les yeux bleux ISA bella
Posté par Tb_ . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 2.
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: "Palette d'instruction": solution au nombre limité d'instructions?
Posté par Tb_ . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 2.
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 ?
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.