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 Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. É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" :)