FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC

Développement d'applications avec le langage Panoramic
 
AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  GroupesGroupes  Connexion  
Derniers sujets
» Klaus est de retour!
par Klaus Aujourd'hui à 3:41

» KGF_dll - nouvelles versions
par Klaus Aujourd'hui à 3:40

» Texte sur image
par JL35 Hier à 23:56

» Compilateur FBPano
par papydall Hier à 14:54

» MIN - MAX avec SPIN
par ygeronimi Hier à 10:02

» Traceur de courbes représentatives des fonctions y = f(x)
par papydall Hier à 2:24

» HEIGHT_CLIENT(N)
par ygeronimi Ven 20 Jan 2017 - 16:41

» Non demande de commande
par ygeronimi Jeu 19 Jan 2017 - 11:50

» Bataille navale sous-marine
par papydall Jeu 19 Jan 2017 - 2:19

» Version instantanée du 16/01/2017 : PANORAMIC V 0.9.27i10
par mindstorm Mer 18 Jan 2017 - 21:05

» PLM N34
par Froggy One Mer 18 Jan 2017 - 17:32

» saving 1.png [RÉSOLU]
par Froggy One Mar 17 Jan 2017 - 19:44

» Gestionnaire de Projets Panoramic
par Froggy One Mar 17 Jan 2017 - 19:31

» ROBLARECUB (casse-tête)
par papydall Mar 17 Jan 2017 - 15:18

» Incrustation d'une image (dans une autre)
par JL35 Mar 17 Jan 2017 - 0:47

Navigation
 Portail
 Index
 Membres
 Profil
 FAQ
 Rechercher
Rechercher
 
 

Résultats par :
 
Rechercher Recherche avancée
Janvier 2017
LunMarMerJeuVenSamDim
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
CalendrierCalendrier

Partagez | 
 

 Pic et Poc, les joyeux drilles

Voir le sujet précédent Voir le sujet suivant Aller en bas 
Aller à la page : Précédent  1, 2, 3, 4
AuteurMessage
Jack
Admin


Nombre de messages : 1590
Date d'inscription : 28/05/2007

MessageSujet: Re: Pic et Poc, les joyeux drilles   Jeu 18 Oct 2012 - 20:29

OK.
ADR_ARRAY() ne doit pas être bien compliqué à coder. Je regarde dès que possible.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://panoramic.free-boards.net
Klaus



Nombre de messages : 9428
Age : 67
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: Pic et Poc, les joyeux drilles   Jeu 18 Oct 2012 - 21:46

Ouahhhhhhhhhh ! Super ! Merci beaucoup pour ton attention !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Nardo26



Nombre de messages : 2294
Age : 48
Localisation : Valence
Date d'inscription : 02/07/2010

MessageSujet: Re: Pic et Poc, les joyeux drilles   Jeu 18 Oct 2012 - 22:10

Merci Jack !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://nardo26.lescigales.org
jean_debord



Nombre de messages : 674
Age : 62
Localisation : Limoges
Date d'inscription : 21/09/2008

MessageSujet: Re: Pic et Poc, les joyeux drilles   Ven 19 Oct 2012 - 10:32

Je soutiens la demande Smile 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 !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://www.unilim.fr/pages_perso/jean.debord/index.htm
silverman



Nombre de messages : 292
Age : 44
Localisation : Picardie
Date d'inscription : 19/03/2015

MessageSujet: Re: Pic et Poc, les joyeux drilles   Dim 16 Oct 2016 - 19:33

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 Embarassed
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 ?
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
papydall



Nombre de messages : 5104
Age : 66
Localisation : Moknine (Tunisie)
Date d'inscription : 03/03/2012

MessageSujet: Re: Pic et Poc, les joyeux drilles   Dim 16 Oct 2016 - 19:57

@ Silverman

Si ça peux t'être utile, j'ai posté ici comment allouer un bloc de mémoire dans le heap.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://papydall-panoramic.forumarabia.com/
silverman



Nombre de messages : 292
Age : 44
Localisation : Picardie
Date d'inscription : 19/03/2015

MessageSujet: Re: Pic et Poc, les joyeux drilles   Dim 16 Oct 2016 - 20:15

Merci papydall, mais je conserve précieusement ton code dans ma bibliothèque depuis un moment déjà Wink
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) affraid
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus



Nombre de messages : 9428
Age : 67
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: Pic et Poc, les joyeux drilles   Dim 16 Oct 2016 - 20:29

@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.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
silverman



Nombre de messages : 292
Age : 44
Localisation : Picardie
Date d'inscription : 19/03/2015

MessageSujet: Re: Pic et Poc, les joyeux drilles   Lun 17 Oct 2016 - 17:35

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

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?
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus



Nombre de messages : 9428
Age : 67
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: Pic et Poc, les joyeux drilles   Lun 17 Oct 2016 - 19:11

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.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Contenu sponsorisé




MessageSujet: Re: Pic et Poc, les joyeux drilles   Aujourd'hui à 4:40

Revenir en haut Aller en bas
 
Pic et Poc, les joyeux drilles
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 4 sur 4Aller à la page : Précédent  1, 2, 3, 4
 Sujets similaires
-
» Pic et Poc, les joyeux drilles
» kit rouge et or joyeux noel pour vous dire bonjour bis beauty
» Joyeux Noel !
» Robin des Bois et ses Joyeux Compagnons
» Joyeux Noël les gens ! <3

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC :: PANORAMIC 32 bits :: Présentation et bavardage-
Sauter vers: