Pour ce que doit faire le shift_right, on est d'accord : il décale à droite et remplace les trous par des zéros. Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes 0 .. 63 ? C'est pour cela que j'avais écrit qu'elle ne faisait vraiment sens que sur cette intervalle. Dans quel contexte va ton réellement lui passer les valeurs 64, 65 ou tout autre supérieure ? Et cela ce n'est pas sans incidence pour un implémenteur de langage haut niveau. Comme tu l'as montré pour ADA : si on évite les valeurs supérieures à 63, on évite un test de comparaison à chaque exécution sur une architecture X86. Quelle intérêt un code pourrait avoir, sur une telle instruction, de se rendre dans un domaine où la sortie vaut toujours 0 ? Et je pense que la raison qui à présider au choix de laisser le comportement non défini en dehors de ces bornes sont des raisons de performances générales : la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86. C'était là le fruit de mes « spéculations », comme celles de Def. Et c'est aussi ce que dit wikipédia :
This helps allow C compilers to emit efficient code for various platforms by allowing direct use of the native shift instructions which have differing behavior.
Ensuite sur ce que fait X86, je n'ai pas dit que c'était délibéré de leur part (bien que ma formulation pouvait laisser penser le contraire) mais je ne faisais que décrire, en me basant sur son comportement, la structure mathématique qui lui correspondait : un opérateur sur un tore, son domaine se ramenant de fait à Z/2^64Z x Z/64Z. Que peut-il servir à modéliser en pratique dans le quotidien d'un programmeur, j'en sais foutre rien et je m'en fout un peu à vrai dire. Mais c'est plus drôle qu'une fonction stationnaire, et c'est joli un donut ! :-P
Quoi qu'il en soit, pour un langage haut niveau qui reproduit l'instruction machine, le développeur ne peut pas s'appuyer sur le comportement de shr sur X86 s'il veut un tel comportement, mais le coder lui-même s'il veut un code portable. Comme il doit le coder lui-même s'il veut que la sortie soit constamment égale à 0.
Pour ce qui est de ton autre question pour OCaml sur PowerPC, je suppose que la réponse est : la sortie est stationnairement nulle à partir de 64. Ce qui est sans doute aussi le cas en C ou C++. Mais je n'ai pas de telle machine à disposition, ni de ARM, pour vérifier.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2. Dernière modification le 19 mai 2017 à 18:10.
Pour ce que doit faire le
shift_right, on est d'accord : il décale à droite et remplace les trous par des zéros. Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes0 .. 63? C'est pour cela que j'avais écrit qu'elle ne faisait vraiment sens que sur cette intervalle. Dans quel contexte va ton réellement lui passer les valeurs64,65ou tout autre supérieure ? Et cela ce n'est pas sans incidence pour un implémenteur de langage haut niveau. Comme tu l'as montré pour ADA : si on évite les valeurs supérieures à 63, on évite un test de comparaison à chaque exécution sur une architecture X86. Quelle intérêt un code pourrait avoir, sur une telle instruction, de se rendre dans un domaine où la sortie vaut toujours0? Et je pense que la raison qui à présider au choix de laisser le comportement non défini en dehors de ces bornes sont des raisons de performances générales : la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86. C'était là le fruit de mes « spéculations », comme celles de Def. Et c'est aussi ce que dit wikipédia :Ensuite sur ce que fait X86, je n'ai pas dit que c'était délibéré de leur part (bien que ma formulation pouvait laisser penser le contraire) mais je ne faisais que décrire, en me basant sur son comportement, la structure mathématique qui lui correspondait : un opérateur sur un tore, son domaine se ramenant de fait à
Z/2^64Z x Z/64Z. Que peut-il servir à modéliser en pratique dans le quotidien d'un programmeur, j'en sais foutre rien et je m'en fout un peu à vrai dire. Mais c'est plus drôle qu'une fonction stationnaire, et c'est joli un donut ! :-PQuoi qu'il en soit, pour un langage haut niveau qui reproduit l'instruction machine, le développeur ne peut pas s'appuyer sur le comportement de
shrsur X86 s'il veut un tel comportement, mais le coder lui-même s'il veut un code portable. Comme il doit le coder lui-même s'il veut que la sortie soit constamment égale à0.Pour ce qui est de ton autre question pour OCaml sur PowerPC, je suppose que la réponse est : la sortie est stationnairement nulle à partir de 64. Ce qui est sans doute aussi le cas en C ou C++. Mais je n'ai pas de telle machine à disposition, ni de ARM, pour vérifier.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.