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é à 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.