bug : PEEK32/POKE32 inverse l'ordre des octets

Ces 2 comandes inversent l'ordre des octets lu/écrit en mémoire, rendant le résultat inexploitable (Il en est de même pour les commandes PEEK16/POKE16).

Code:

dim a%,b%,i%

' ecrire dans a% la série d'octet : 001 002 003 004
a%=001*power(256,3) + 002*power(256,2) + 003*power(256,1) + 004*power(256,0)
print "a% contient la série d'octet : 001 002 003 004"
' copier a% dans b%
b%=peek32(adr(a%))
print "a% est copié dans b% via la commande PEEK32"
print

print "lecture de a%:"
for i%=3 to 0 step -1
  print peek(adr(a%)+i%);"  ";
next i%

print:print

print "lecture de b%:"
for i%=3 to 0 step -1
  print peek(adr(b%)+i%);"  ";
next i%

silverman a écrit:

a% contient la série d'octet : 001 002 003 004

Eh bien non.

En faisant

Code:

a%=001*power(256,3) + 002*power(256,2) + 003*power(256,1) + 004*power(256,0)

Tu n'écris pas dans a% la série d'octet : 001 002 003 004, mais la série d'octets 004 003 002 001

La preuve:

Code:

dim a%
a%=001*power(256,3) + 002*power(256,2) + 003*power(256,1) + 004*power(256,0)

print "a% contient la série d'octet : 004 003 002 001"

print peek(adr(a%))
print peek(adr(a%+1))
print peek(adr(a%+2))
print peek(adr(a%+3))

Comme l'a fait remarquer Marc:

Marc a écrit:

Je viens de lire cet article sur l'organisation des données :
https://fr.wikipedia.org/wiki/Endianness
Très intéressant !
Bonne programmation à tous !

Windows est du type "Little Endian"

En utilisant POKE32 et PEEK32() avec une adresse de variable entière, tu as l'impression que tout est inversé.
Mais PEEK32() et POKE32 ne sont pas faits pour être utilisés uniquement avec des adresses de variables entières.

En effet, j'ai commis une erreur, c'est bien la séquence 004 003 002 001 qui est écrite. Cependant, ça ne change pas le fait que pour un même mode de lecture, l'ordre des octets est inversé.
Comme l'a évoqué klaus ici, les valeurs telles qu'elles sont retournées actuellement ne sont pas directement exploitable pour nous, les panoramiciens.
Par exemple a%=peek32(adr(machaine$)) ne retourne pas l'adresse correctement puisque l'ordre des octets est inversé. Transmettre cette adresse dans un DLL_CALLx("fonction_quelconque",a%) conduit à un plantage.