Bonjour,
à propos des instruction d'un programme , par exemple; déclaration des variables , des library , main ...etc .je veux savoir où est ce qu'elle est stocké chaque instruction?
par exemple : int i, j ; ==> est stocké dans la RAM et pour les autres? svp si qlq'un peut me donner un exemple de programme en me citant la mémoire de stockage de chaque instruction !!
Merciiiii.
Bonjour
Ça dépend des systèmes, des outils de développements utilisés et de leur paramétrage.
Sur les gros systèmes (type PC industriel), tout se retrouve en RAM.
Sur les petits systèmes (microcontrôleurs), le code exécutable et les données constantes sont souvent stockées en ROM (ou en mémoire Flash). Mais dans certains cas les données constantes peuvent être stockées en RAM et initialisées au démarrage, voire en EEPROM.
Si tu veux savoir comment cela se passe sur le système auquel tu penses, lis sa documentation et celle de ton outil de développement (i.e. la chaîne de compilation C que tu utilises).
Dernière modification par PA5CAL ; 26/04/2012 à 11h04.
J'oubliais... certains stockages de données peuvent être pratiqués dans des registres plutôt que dans la RAM. Le fait que ces données soient stockées dans l'un ou l'autre espace peut être fixé par l'outil de développement (parfois sous le contrôle du programmeur, parfois non), ou déterminé par la gestion dynamique des ressources au cours de l'exécution du programme.
Bref, il faut voir au cas par cas...
Dernière modification par PA5CAL ; 26/04/2012 à 11h16.
Salut,
la solution s'appelle un debugger. Il en existe pratiquement pour tout type de processeur. Tu peux par exemple avec Unix, ou Linux utiliser GDB qui "trace" pratiquement tout, et qui te donne le listing assembleur. On voit ainsi très bien où sont rangées les variables, ainsi que les pointeurs qui délimitent les zones "globales" ou "locales" et les variables système, tout quoi. Bien qu'il soit plus simple à utiliser si au moment de la compilation tu as "autorisé" le mode déboguage, on peut toujours, moyennant quelques astuces, le faire sur tout programme en cours d'exécution. Sur Mac c'est ce que j'utilise, sur PC, je connais aussi un truc qui s'appelle ADA.
L'avantage, quand on est l'auteur du logiciel à tracer et que l'on a prévu cette option à la compilation, est que le nom des modules externes ou des routines est parfaitement visible et en clair. Sinon ces zones apparaissent sous la forme d'une adresse. Que l'on peut d'ailleurs renommer quand on pense en avoir compris la fonction.
Dernière modification par azad ; 26/04/2012 à 11h36.
MERCI bcp,
Mais juste pour le main () du programme c commun je pense il se stocke où ! je pense que certains instruction se stocke tt le temps ds le mm endroit ?!!
merci
Ça dépend...
Comme tu ne dis absolument rien sur la plateforme et l'outil de développement que tu utilises, il ne peut y avoir de réponse précise à ta question.
Pour te donner un exemple, j'ai actuellement un petit programme pour microcontrôleur qui stocke toutes ses variables en RAM. Sans rien modifier au code de ce programme, juste en touchant aux options de compilation, toutes ces variables sont stockées dans des registres, plus aucune ne restant en RAM...
j'ai comme microcontrôleur dspic30f4011 , j’utilise MPLABX
Et pourquoi tu te passionnes pour la position en RAM de tes variables ? C'est ça l'intérêt du C , on s'en moque (en première approximation !)
J'aime pas le Grec
bahya :
Le "main" est sans doute le plus facile à localiser, point d'entrée oblige. Le plus intéressant quand on veut tracer un programme est encore la boucle principale d'événements : c'est là que "se repose" le logiciel quand il attend que l'usager (ou le système) ait déclenché quelque chose qu'il est censé savoir faire. Parce que, tu t'en doutes, tous les "events" ne sont pas toujours pris en compte. Par exemple l' événement "insertion de disquette" est rarement envisagé !!
Mais rien de ce que je raconte ici, n'est vraiment applicable dans le cas d'un micro-contrôleur, ce n'est valable que pour les microprocesseurs. Pour les µ-contrôleurs, je pense qu'il doit exister des outils de débogage, mais ils ne devraient (selon mon avis) n'opérer que sur le code source - avant compilation donc - Parce qu'après, c'est fini ! on n'a pas accès aux bus adresses ou data, seules les sorties des différentes interfaces sont accessibles. Par exemple le ou les PIA, UART, internes sont invisibles. Je pense la chose impossible même sans doute pour le fabricant de la puce. Par contre une (très) bonne connaissance de l'architecture de la puce, de son jeu d'instruction, gestion de pile, ou autres programmes internes de traitement d'interruption ou garbage et tout le tralala, devrait permettre de simuler (je dis bien simuler ) l'exécution du programme en ayant le source sous les yeux. Et ce ne sera qu'une simulation, car d'une part, on ne connaît généralement rien des micro-instructions internes, et pas grand chose de la façon dont le compilateur traite le source.
Faites moi signe si je me trompe.
Sur beaucoup de compilateur, tu peux accéder au code assembleur (code machine) généré. Ce qui permet de voir si ton compilateur n'est pas trop con et parfois de l'optimiserEnvoyé par azad
J'aime pas le Grec
