PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV (précédentes versions) → J'en perd mon binaire...
J'en perd mon binaire...
Débuté par Philippe Pasquali, 16 nov. 2019 20:23 - 7 réponses
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.