Pic et Poc, les joyeux drilles

OK.
ADR_ARRAY() ne doit pas être bien compliqué à coder. Je regarde dès que possible.

Ouahhhhhhhhhh ! Super ! Merci beaucoup pour ton attention !

Merci Jack !

Je soutiens la demande Une telle fonction serait très utile. Même si elle ne concerne pas directement le "programmeur du dimanche", elle facilitera l'écriture de DLLs qui profiteront à tout le monde.

Je suis un peu dépassé par les derniers travaux de Klaus. Au début j'y voyais un exercice intéressant sur les pointeurs mais maintenant j'ai du mal à suivre. Donc tout ce qui pourra simplifier sera la bienvenu !

Bonjour à tous

Je remonte ce vieux sujet afin éviter d'éparpiller de potientielles nouvelles infos concernant les tableaux.

@klaus
Mes questions sont plus pour toi, car tu as le plus avancé dans le domaine des peek, poke, table des variables, etc...

klaus a écrit:

En cours d'exécution du programme, l'allocation de mémoire change dynamiquement, et même des parties de la table des variables, de même que les emplacements des données des tableaux sont régulièrement déplacés. Donc, mes adresses qui étaient valables en début de programme ne le sont plus du tout en coure de programme, et elles évoluent même au cours de l'exécution.

Je suis donc à la recherche d'un moyen plus fiable de localiser les données.

Tu as concentré tes recherches sur les tableaux, mais pourquoi utiliser les tableaux avec les dlls, ça a quelle utilité?
Si j'ai bien compris, les élements d'un tableau ne se suivent pas forcémément, ils sont éparpillés dans la mémoire, c'est bien ça? Mais alors, coment as tu fait pour déterminer l'emplacement d'un élément de tableau en mémoire?
A un moment, tu as parlé de mémoire virtuelle, les données sont stockées en mémoire physique ou virtuelle? C'est flou pour moi, je ne maitrise pas le concept de mémoire virtuel
L'allocation de mémoire change dynamiquement, par ex:

Code:

dim a
print adr(a)
dim b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z
print adr(a)

es tu parvenu à contouner ce pb? Sait tu retrouver la nouvelle adresse de 'a' dans cet exemple ?

@ Silverman

Si ça peux t'être utile, j'ai posté ici comment allouer un bloc de mémoire dans le heap.

Merci papydall, mais je conserve précieusement ton code dans ma bibliothèque depuis un moment déjà
Je n'ai pa pu intégrer ces fonctions avec le nouveau système de library, car il y a des informations de déboguage qui apparaissent(éxécution pas à pas)

@Silverman:
Dans l'exemple que tu as donné, l'adresse de "a" ne change pas, en réalité. Mais l'adresse d'une variable peut changer (selon mon expérience), si tu en détruis et tu en crées d'autres (potentiellement avec le même nom, pas pas seulement). Considérons ceci:

Code:

dim a,b,c
delele b
dim d,e,b,f

La variable b est créée initialement, puis supprimée et recréée plus tard. Mais sa nouvelle adresse n'a plus rien à voir avec son adresse initiale.

Le problème se complique avec les tableaux. Pour un tableau en une seule dimension, je peux retrouver, avec un peu de "gymnastique", l'adresse de la première cellule du tableau, et les autres sont physiquement rangés à la suite. Mais c'est plus compliqué avec les tableaux en deux dimensions. Alors que l'élément (0,0) est toujours localisable (et les éléments suivants dans la même "ligne", comme (0,1), (0,2) etc), il est plus compliqué de trouver la deuxième ligne (cellules (1,0), (1,1), etc) et ainsi de suite. Elles ne sont pas du tout localisées après la dernière cellule de la première ligne, ce que l'on aurait pu supposer. Je n'ai pas réussi à trouver un algorithme fiable qui trouve ces lignes à coup sûr.

Un petit mot sur la notion de mémoire virtuelle. C'est une notion essentielle, mais c'est géré de façon entièrement automatique par le système d'exploitation. D'abord, une approche intuitive: chaque programme a une adresse 0. Or, plusieurs programmes exécutant simultanément ont tous une adresse 0. Où est-elle physiquement ? Et si un programme se termine et libère sa mémoire, et un autre programme plus gros veut démarrer, qu'est-ce qui se passe ? Qu'est-ce qui se passe si un très gros programme veut démarrer et il n'y a plus assez de mémoire physique ? C'est là qu'interviennent les notions de mémoire physique, mémoire virtuelle et le processus de swapping et de pagination.

Depuis les débuts de la programmation, le programmeur est confronté aux limites de la mémoire physique. Au départ, on avait un seul programme pouvant exécuter, et une mémoire qui était ce qu'elle était, par exemple 16ko (oui, kilo-octets !), jusqu'à 64ko pour des machines 16 bits. Un mot machine de 16 bits a justement la capacité de fournir une adresse entre 0 et 64ko-1 (65535). Il en va de même pour les machines de 32 bits (de 0 à 2^^32-1) etc.

Donc, très rapidement, on a inventé deux mécanismes. Le premier était le "swapping", et windows a toujours un fichier swap ! Cela permet de copier dans un fichier géré par le système, la totalité d'un programme en cours d'exécution, de charger un autre pour l'exécuter, puis faire de même pour ce dernier et recharger le précédent, etc. C'étaient les débuts de la programmation multi-tâches.

Mais il fallait aller plus loin. D'abord, il est très pénalisant pour les performances globales de tout recopier et relire du disque. Puis, plusieurs programmes peuvent éventuellement cohabiter simultanément en mémoire. Mais il fallait que chaque programme puisse s'exécuter comme s'il était seul aux commandes. Et donc, chaque programme devait avoir le même "champ d'adressage". Et c'est la que la notion de "mémoire virtuelle" a été conçue. Le système alloue à chaque programme une zone de mémoire "privative" et se charge de traduire toutes les adresses fournies par le programme (les adresses virtuelles) en adresses physiques. Initialement, c'était fait par un dispositif hardware. Plus tard, le logiciel et un firmware spécialisé a pris le relais. Et c'est ainsi que chaque programme peut avoir son adresse virtuelle 0, dont l'emplacement physique en mémoire centrale peut varier d'un instant à l'autre et est gérée exclusivement par le système d'exploitation, et toute transparence.

Mais, il fallait aller plus loin. Lorsqu'un veut faire cohabiter des dizaines de processus en mémoire simultanément, ce qui est le cas en permanence dans nos systèmes, on ne peut plus raisonner sur des programmes en entier. On a introduit la notion de "page" de mémoire virtuelle. Une page est une portion physiquement contigüe de mémoire. La totalité de la mémoire d'un programme est divisée en "pages" dont l'emplacement physique est géré par le gestionnaire de mémoire du système (memory manager), en totale transparence. Et il y a un fichier de pagination dans lequel le système (Windows aussi !) décharge des pages de mémoire momentanément peu ou pas demandées pour libérer de la mémoire physique pour la création ou le chargement d'autres pages. Tout cela est entièrement transparent.

Je ne vais pas aller plus loin dans la description de ces mécanismes. Sache que la totalité de la mémoire allouée à un programme s'appelle son champ d'adressage et représente sa mémore virtuelle. Elle va de 0 à un maximum qui dépend du programme, mais est limitée par les possibilités physiques d'adressage (2^^32-1 sur une machine 32 bits, et 2^^64-1 sur une machine 64 bits). Bien entendu, les dimensions de la mémoire virtuelle peuvent dépasser lar.gement les limites de la mémoire physique. Et c'est tout l'intérêt de la notion de mémoire virtuelle que de dépasser cette contrainte physique. La mémoire virtuelle d'un programme est automatiquement divisée en pages dont l'emplacement en mémoire physique est recalculé et réajusté en permanence, par le système.

Ainsi, lorsque tu fais un PEEK ou un POKE, tu le fais dans la mémoire virtuelle, et tu n'as aucune idée de l'adresse physique où ça tombe. Et cela n'a d'ailleurs aucune importance pour le programmeur, tant qu'il se limite à son seul programme. Tout change lorsqu'on veut communiquer entre deux programmes, mais là, c'est un autre problème qui dépasse la présente discussion.

Voilà. J'espère que le ne t'ai pas trop perturbé...

EDIT

J'en rajoute une couche, pour parler des DLLs.

Les DLLs sont des collections de fonctions appelables par n'importe quel exécutable Windows, à conditiion des respecter les conventions d'appel, bien sûr. Une DLL est un fichier ayant à peu de chose près la même structure qu'un fichier EXE. Lorsqu'un programme veut accéder à une DLL (par DLL_ON en Panoramic), le système place une copie de la DLL dans la mémoire virtuelle du programme en question, en agrandissant l'espace virtuel alloué au programme. On voit ainsi immédiatement que, si plusieurs programmes utilisent la même DLL, chacun a sa copie privative et aucune communication de données ne peut avoir lieu entre les programmes à travers les données de la DLL, puisque justement, ces donneés, pour chaque programme, résident dans la copie privative dans son propre espace de mémoire virtuelle.

Et une conséquence importante, capitale, de tout cela, c'est qu'aucune adresse (valeur retournée par la fonction adr() de Panoramic) n'est universelle ni absolue. Une adresse retournée par la fonction adr() est une adresse dans la mémoire virtuelle du programme qui a appelée la fonction, et n'est valable qu'à l'intérieur de ce programme. Pire, elle n'est valable que pendant la durée de vie du programme. Si ce programme est arrêté et relancé, le même appel à la fonction adr() retournera très certainement une valeur différente. Et deux programmes identiques tournant simultanément et appelant adr() pour trouver l'adresse d'une variable, récupéreront éventuellement une valeur différente. Et même s'ils récupèrent la même valeur, celle-ci représente une adresse virtuelle dans la mémoire virtuelle du programme appelant, et qui correspond à une adresse physique totalement différente de la même adresse virtuelle du deuxième programme, lancé pourtant à partir du même EXE et tournant simultanément. Il est donc impossible de communiquer des adresses entre programmes, ou même de mémoriser des adresses dans un fichier pour les utiliser plus tard.

C'est beaucoup plus clair maintenant!     En plus, tu as devancé ma question sur 'ADR'

Cependant, dans l'exemple que je donne, la variable 'a' a une adresse différente après une certaine quantité de 'DIM'.
Vu que tout ce passe en mémoire physique, et puisque l'adressage de la mémoire virtuelle commence en 0, selon moi ça ne peut être que panoramic qui réorganise les données dans le cas de la variable 'a', pas windows.
Mais je ne comprend toujours pas pourquoi utiliser les tableaux avec les dlls, ça a quelle utilité? Suivant le cas, ça ne serait pas mieux de passer par un système(maison) de structure?

Et une "structure", c'est quoi d'autre qu'un tableau évolué ?

L'intérêt de passer des paramètres dans un tableau est double. D'une part, cela permet de dépasser la limite de 6 paramètres pour les appels DLL, et on peut passer un nombre quasiment illimité, et ce en entrée et sortie. Et d'autre part, dès l'instant qu'on veut accéder aux APIs de Windows (qui sont tous dans des DLLs de Windows, comme USER32.dll par exemple), il faut souvent passer l'adresse d'un tableau dans lequel chaque position a une signification bien précise.

Actuellement, Panoramic limite le nombre de paramètres d'une fonction DLL à 6, et se sont uniquement des entiers passés "par valeur". En passant l'adresse d'un tableau, on pourrait aisément dépasser cette limite.

Pour ce qui est la valeur de l'adresse d'une variable en Panoramic, ce dernier gère l'allocation de la mémoire virtuelle à ses variables, selon son bon vouloir. Et note bien: ce qui change, c'est l'adresse virtuelle. Celle-ci n'a aucun rapport avec l'adresse physique. Cette dernière peut changer d'un instant à l'autre, à l'insu du programme et à l'insu de Panoramic, dès l'instant que Windows change une page de mémoire virtuelle de place, ce qui arrive très fréquemment.