Pour ton 1. : pourquoi renvoyer une erreur (ie lever une exception) ? Qu'est-ce qui le justifierait ? Je ne me place pas dans la logique du hardware mais plutôt de ce pour quoi est fait un proco: faire du calcul mathématique.
Pour ton 2. le résultat d'un shift à droite est borné (par les bornes de l'opérande de gauche) et toujours mathématiquement défini. Donc il n'y a rien à gérer ici en terme de "saturation".
Pour ton 3. L'arithmétique modulaire est la base de calcul de tous les processeurs courants. C'est à dire que l'ensemble des opérations arithmétiques +, -, * doit donner un résultat juste modulo 2^n où n désigne le nombre de bits (commun) des entiers machines manipulés. Il n'y a donc jamais ni d'"underflow" ni d'"overflow" chez les entiers machines. Par contre, l'utilisateur final qui ne connaîtrait pas ce mode de fonctionnement pourrait interpréter les résultats modulaires comme des erreurs de calcul.
Par exemple, si je veux le quotient de 3^{65536} par 256, on peut procéder en C avec le code suivant
unsignedcharu=3,i=0;// Je décide de calculer avec u modulo 256 for(;i<16;i++,u*=u);// J'élève 16 fois au carré successivement la variable u// Je suis certain, qu'en sortie, le calcul a été fait dans l'anneau des entiers modulaires modulo 256 et que u contient le résultat.
On pourrait croire dans cet exemple qu'il y a de l'overflow de partout, mais il n'en est rien. Tout est calculé modulo 256 et c'est dans le cahier des charges du processeur que de bien respecter cette règle.
Pour ce qui concerne l'opération de shift à droite, elle ne fait pas partie des opérations +, - , * et ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2^{n-1} par une puissance positive quelconque de 2. En ce sens, le résultat initial devrait donner 0 (en tout cas jamais 1 !).
Que le jeu d'instructions du processeur exige pour des raisons techniques des arguments bornés, on peut le comprendre, mais que des langages au dessus reproduisent la même chose, je ne comprends pas l'intérêt (à vrai dire il n'y a pas d'intérêt à laisser le résultat indéfini alors qu'il y a un sens tout à fait évident à donner).
D'ailleurs je ne suis pas surpris qu'Ada ou Haskell donnent le comportement attendu (le comportement inattendu étant même qualifié de 'unsafe' par le compilo).
[^] # Re: C'est décrit dans la spec de Java
Posté par snowball (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 3.
hmmmm,
Pour ton 1. : pourquoi renvoyer une erreur (ie lever une exception) ? Qu'est-ce qui le justifierait ? Je ne me place pas dans la logique du hardware mais plutôt de ce pour quoi est fait un proco: faire du calcul mathématique.
Pour ton 2. le résultat d'un shift à droite est borné (par les bornes de l'opérande de gauche) et toujours mathématiquement défini. Donc il n'y a rien à gérer ici en terme de "saturation".
Pour ton 3. L'arithmétique modulaire est la base de calcul de tous les processeurs courants. C'est à dire que l'ensemble des opérations arithmétiques +, -, * doit donner un résultat juste modulo 2^n où n désigne le nombre de bits (commun) des entiers machines manipulés. Il n'y a donc jamais ni d'"underflow" ni d'"overflow" chez les entiers machines. Par contre, l'utilisateur final qui ne connaîtrait pas ce mode de fonctionnement pourrait interpréter les résultats modulaires comme des erreurs de calcul.
Par exemple, si je veux le quotient de 3^{65536} par 256, on peut procéder en C avec le code suivant
On pourrait croire dans cet exemple qu'il y a de l'overflow de partout, mais il n'en est rien. Tout est calculé modulo 256 et c'est dans le cahier des charges du processeur que de bien respecter cette règle.
Pour ce qui concerne l'opération de shift à droite, elle ne fait pas partie des opérations +, - , * et ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2^{n-1} par une puissance positive quelconque de 2. En ce sens, le résultat initial devrait donner 0 (en tout cas jamais 1 !).
Que le jeu d'instructions du processeur exige pour des raisons techniques des arguments bornés, on peut le comprendre, mais que des langages au dessus reproduisent la même chose, je ne comprends pas l'intérêt (à vrai dire il n'y a pas d'intérêt à laisser le résultat indéfini alors qu'il y a un sens tout à fait évident à donner).
D'ailleurs je ne suis pas surpris qu'Ada ou Haskell donnent le comportement attendu (le comportement inattendu étant même qualifié de 'unsafe' par le compilo).