| |
Membre enregistré 945 messages Popularité : +102 (110 votes) |
|
Posté le 16 novembre 2019 - 20:23 |
Bonjour, [Windev20] Je sais que mes cours d'assembleur Z80 sont très très loin mais je trouve très bizard le résultat de l'instruction «bitDécaleDroite» avec des entiers sans signe sur 8 octets.
x est un entier sans signe sur 8 octets = 0x8000000000000000 y est un entier sans signe sur 8 octets Trace(NumériqueEnChaineBinaire(x,Faux)) affiche 1000000000000000000000000000000000000000000000000000000000000000 tout va bien y = bitDécaleDroite(x,4) Trace(NumériqueEnChaineBinaire(y,Faux)) affiche 1111100000000000000000000000000000000000000000000000000000000000 hors je m'attendais à 0000100000000000000000000000000000000000000000000000000000000000
Dans l'aide il est pourtant écrit Le type de résultat peut être différent selon le type de l'opérande : Opérande Valeur 1 Résultat Entier sur 4 Entier sur 4 Entier sur 8 Entier sur 8 Autre Entier sur 8
Même remarque avec l'instruction «OUExclusifBinaire» mais là dans l'aide il est clairement mis que c'est pour des entiers donc 4 octets. Là ou j'en perd mon binaire c'est que l'instruction «||» qui selon l'aide est censé faire lui aussi un OU exclusif binaire : <Valeur 1> || <Valeur 2> fonctionne très bien... x = 1111111111111111111111111111111111111111111111111111111111111111 y = 0011001100110011001100110011001100110011001100110011001100110011 OUExclusifBinaire(x,y) -> 1111111111111111111111111111111111001100110011001100110011001100 x || y -> 1100110011001100110011001100110011001100110011001100110011001100
je ne rappelle pas qu'il y avait deux façons de faire un XOR ?
-- L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai. Quand un utilisateur vous a aidé, n'oubliez pas de le remercier... |
| |
| |
| | | |
|
| | |
| |
Posté le 18 novembre 2019 - 11:10 |
Bonjour
C'est en effet très étrange.
J'ai testé votre code sous WD 23 et 24 et voici le résultat.
x est un entier sans signe sur 8 octets = 0x8000000000000000 y est un entier sans signe sur 8 octets Trace(NumériqueVersChaîneBinaire(x)) y = bitDécaleDroite(x,4) Trace(NumériqueVersChaîneBinaire(y))
PROCEDURE INTERNE NumériqueVersChaîneBinaire(i_ est un entier sans signe sur 8 octets) chRetour est une chaîne POUR i = Dimension(i_) * 8 À 1 PAS -1 chRetour += i_[i] FIN RENVOYER chRetour FIN
Sous WD23 : -1000000000000000000000000000000000000000000000000000000000000000 -1111100000000000000000000000000000000000000000000000000000000000
Sous WD24 : -1000000000000000000000000000000000000000000000000000000000000000 0000100000000000000000000000000000000000000000000000000000000000
On constate donc une petite amélioration en V24.
Mais il semble donc que WD considère toujours les entiers sur 8 octets comme signés même s'ils sont déclarés non signés. D'ailleurs en débogage pas à pas, on constate une alerte de dépassement de capacité. Mais la bulle du débuggueur renvoie bien la bonne valeur sans signe!
Et le truc rigolo en plus c'est que le bit de gauche renvoie -1. Je veux bien que c'est le bit de signe mais sa conversion ne peut être que 0 ou 1. Les bits n'ont pas de signe.
Pour le problème du ou exclusif, on constate la même chose que ce que vous exposez aussi bien en 23 qu'en 24.
OuExclusifBinaire : -1111111111111111111111111111111111001100110011001100110011001100
Opérateur || : -1100110011001100110011001100110011001100110011001100110011001100
Bon dev.
Laurent M. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 1 143 messages Popularité : +50 (142 votes) |
|
Posté le 18 novembre 2019 - 11:58 |
Bonjour, J'ai testé votre code sauf qu'on obtient un dépassement de capacité lors de l'affectation à x (en tout cas c'est le message que j'ai). l'erreur ne viendrait-elle pas de là? en enlevant 2 zéros le compte est juste.
Thierry |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 1 143 messages Popularité : +50 (142 votes) |
|
Posté le 18 novembre 2019 - 12:45 |
et bizarrement
x est un entier sans signe sur 8 octets =HexaVersEntier("8000000000000000")
ne m'indique pas de dépassement de capacité (je suis en 64bits). |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 1 143 messages Popularité : +50 (142 votes) |
|
Posté le 18 novembre 2019 - 12:50 |
Cela ne viendrait pas du fait qu'on utiliser WinDev version 32 bits au lieu de la version 64 ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 945 messages Popularité : +102 (110 votes) |
|
Posté le 18 novembre 2019 - 13:06 |
Bonjour @ Laurent M, merci de m'avoir confirmé qu'il y a bien n soucis. Il n'y a qu'a espérer que PcSoft corrige dans sa prochaine mise jour. @THIERRY TILLIER, merci à vous aussi. Windev est bien en 32bits, mais je compile et exécute en 64 bits.
-- L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai. Quand un utilisateur vous a aidé, n'oubliez pas de le remercier... |
| |
| |
| | | |
|
| | |
| |
Posté le 18 novembre 2019 - 14:17 |
@THIERRY TILLIER Je signalais bien le dépassement de capacité et pour moi cela vient du fait que WD considère que la variable est signée alors qu'elle est déclarée non signée. En effet, si je retire 2 zéros comme vous le suggérez, dans ce cas le compte n'est pas juste et j'obtiens ceci : 0000000010000000000000000000000000000000000000000000000000000000 0000000000001000000000000000000000000000000000000000000000000000
Quant au HexaVersEntier, ok il n'y a plus l'alerte de dépassement de capacité mais le problème est toujours là pour la manipulation des bits. (apparition du - )
Pour ma part, j'ai fait les test sur WD 23 et 24 en 64bits sur des projets en 32 et 64 bits.
Espérer que PCSoft corrige est une chose mais il faut qu'ils soient au courant du problème. Pour cela il faut envoyer une requête au ST avec un mini projet qui expose clairement le souci.
Bon dev.
Laurent M. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 1 143 messages Popularité : +50 (142 votes) |
|
Posté le 18 novembre 2019 - 21:22 |
@Laurent, enlevé les deux zéros n'était pas une solution que je suggérais, je voulais juste vérifier le dépassement. la valeur utilisée pour x est supérieur de 1 à la valeur maximale du 64 bit non signé. mais cela ne résout pas le problème. Je suis d'accord avec vous.
Une autre piste peut-être : sur un des projets que sur lequel j'ai travaillé, je programmais un lecteur de carte NFC et j'ai dû inversé le poids fort et le poids faible pour avoir une valeur correcte. |
| |
| |
| | | |
|
| | |