incohérence POKE32

Bonjour à tous

Contrairement à PEEK32, POKE32 ne supporte pas les nombres négatifs. Il le devrait puisque les variables entières en panoramic sont signées.

Code:

dim a%,b%      
a%=1
poke32 adr(b%),a%      :' écrire 1 dans la mémoire à l'adresse b%
print peek32(adr(b%))  :' montrer le contenu de la mémoire à l'adresse b%
poke32 adr(b%),b%      :' inverser l'ordre des octets pour afficher correctement b%
print b% : print
a%= -1
poke32 adr(b%),a%      :' <--- ERREUR !!!   écrire -1 dans la mémoire à l'adresse b%  
print peek32(adr(b%))  :' montrer le contenu de la mémoire à l'adresse b%
poke32 adr(b%),b%      :' inverser l'ordre des octets pour afficher correctement b%
print b%

Pour moi, le fait que cela soit signé ou non devrait plutôt être un paramètre car une valeur sur 32 bit n'est pas forcément un entier signé même s'il peut l'être.
La même remarque peut s'appliquer au 64 bits, il faudrait rajouter un paramètre pour préciser la nature de la valeur attendue (signée ou non)

Je ne pense pas que ce soit nécessaire. Peek, Poke et se dérivés attendent des adresses, et par nature, une adresse est en nombre non signé de 32 ou 64 bits. En Panoramic, il n'y a que des entiers, et donc, une adresse peut être vue comme un nombre négatif, mais ça reste néanmoins un ordinal non signé sur 32 ou 64 bits. Il faut bien entendu que Panoramic laisse passer ces valeurs - à Windows ensuite de rejeter ou non en cas de violation de mémoire.

klaus a écrit:

Peek, Poke et ses dérivés attendent des adresses, et par nature, une adresse est en nombre non signé de 32 ou 64 bits.

Tout est là.
POKE32 d'une adresse de variable n'est qu'un cas particulier de l'utilisation de POKE32.
Ajouter un paramètre pour ce cas particulier irait trop loin.
Pourquoi pas un autre paramètre indiquant qu'on écrit dans la mantisse d'une variable réelle, ou dans son exposant, ou qu'on écrit dans un complément à 2 d'une variable entière négative, etc.

C'est trop compliqué et pas le but de PEEK(), POKE et dérivés.

Bien, je comprend. PEEK32 m'a donné des adresses négatives et je comptais sur POKE32 pour régler le pb. Je viens de remarquer que PEEK32 lit les adresses à l'envers d'ou la question suivante:
pourquoi PEEK32 lit les adresses à l'envers?
En fait c'est cette commande qui me pose un pb maintenant... Obtenir l'adresse qui donne accès aux octets qui compose une string n'est pas aisé directement. "a%=PEEK32(adr(machaine$))" ne retourne pas le résultat que j'attendais; je pensais transmettre cette adresse à une dll windows, mais ce n'est compatible, il faut passer par une bidouille

D'après mes tests, Peek32 retourne bien la bonne suite de 4 octets, mais dans l'ordre inversé ! C'est ce qui rend ce résultat inexploitable. Il s'agit ici clairement d'un bug.

Bonjour à tous !

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 !

klaus a écrit:

D'après mes tests, Peek32 retourne bien la bonne suite de 4 octets, mais dans l'ordre inversé ! C'est ce qui rend ce résultat inexploitable.

Ouf, ça me rassure! Je l'ai vite remarqué, c'est pour ça que j'utilisais POKE32 pour inverser l'ordre des octets, car cette commande les inverse également.

Un code pour montrer le pb:

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

Voici la preuve du problème, Jack. Je crée une variable string contenant "ABCD". J'affiche la valeur hexa de peek32(adr(cette variable)). En même temps, j'appelle une fonction DLL en passant adr(cette variable) en paramètre. Je place dans le titre de la form 0 la représentation hexa de adr(cette variable), le contenu du mot pointé par cette adresse (ce qui est l'adresse du début des données de la chaine de caractères), puis le mot pointé par cette adresse (ce qui affiche les 4 premiers caractères en hexa), puis la chaîne elle-même lue par la fonction DLL.

Or, on constate que, alors que la DLL accède parfaitement normalement à la chaîne, la valeur retournée par peek32 donne bien les bons octets, mais dans l'ordre inverse. Et, partant de là, cette valeur n'est pas utilisable comme adresse pour des traitements ultérieurs.

Voici la fonction DLL:

Code:

function TestAdr(hnd: HWND; a: integer):integer; stdcall; export;
var
  i1, i2: integer;
  s: string;
begin
  i1 := pinteger(a)^;
  i2 := pinteger(i1)^;
  s := inttohex(a,8)+'  '+inttohex(i1,8)+'   '+inttohex(i2,8)+'   '+pstring(a)^;
  sendmessage(hnd,WM_SETTEXT,0,integer(@s[1]));
  result := 0;
end;
exports TestAdr;

Et voici le code Panoramic:

Code:

dim MaChaine$, a%, b%, res%
MaChaine$ = "ABCD"
dll_on "KGF.dll"
a% = peek32(adr(MaChaine$))
res% = dll_call2("TestAdr",handle(0),adr(MaChaine$))
display
message "a%="+hex$(a%)
end

Et le résultat:


Compare l'affichage du message Panoramic avec le deuxième nombre hexa affiché dans la barre de titre...

@Klaus:
dans la version instantanée V 0.9.28i17, j'ai inversé l'ordre des octets de PEEK16() et PEEK32().

Super ! Merci !