Bonjour Jack,
Je suis tout à fait d'accord avec vous, mais je ne comprend pas très bien l'intérêt de cette question (cad à propos de la pile), sauf naturellement pour ceux qui travaillent au niveau du code machine.
A mon avis, pour un développeur lambda, les principes à appliquer dans ce domaine sont assez simple, en gros, éviter plus de 4 variables en paramètre, les fonctions par récurrence remplissent la pile jusqu'à la faire déborder etc.
salut
moi je connais pas bien le français et je ne sais pas comment t'expliquer ça mais je vais essayer
pour les paramètres ces sont les variables char ou int ces placer dans la ram exemple
la l'instruction (return data) returné la valeur de data a la variable read_eeprom ( le nom de la fonction elle meme est une variable de type (unsigned char) exemple (read_eeprom = dataCode:unsigned char read_eeprom(int adresse ) { uchar data; registreadresse = adresse ; // exemple l'envois de l'adresse x instruction x instruction return data; }et indiquer en meme temps au proccesseur que c'est la fine de la fonction read_eeprom(); pour restorer l'encien addess de l'appel (pile vers pc) , voir exemple de l'appel dans la fonction main()
et c'est la meme chose pour les paramètres d'entrer exempleCode:void main() { inBuffer[0] = read_eeprom(0x45); // c'est la le moment de passer l'adresse de la fonction read_eeprom // dans la pile avan de sauté } // ( c'est l'adresse de la variable read_eeprom qui va passer dans la pile)
tous ça na plus besoin d'encombrer la pile car on a les variables des paramètres prés definé et typé pour recevoir des tableaux & data ou des adresses a lireCode:inBuffer[0] = read_eeprom(0x45); // imagine ce code comme par exemple // inBuffer[0] = read_eeprom(int adresse = 0x45); // ou pouvez aussi imaginer la fonction sans parentaise "()" inBuffer[0] = read_eeprom ; // et le paramètre aussi comme variable normal par adresse = 0x45;
désolé pour la langue j'ai déclaré d'avance que je ne connais pas le français (pas besoin de m'indiquer ça en rouge )
la tu as raisonEnvoyé par Jack
Tu te débrouilles assez bien en français.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Oui c'est normal puisque la pile est forcément en RAM.pour les paramètres ces sont les variables char ou int ces placer dans la ram exemple
En C, tu as 3 zones mémoire pour les variables:
- une pour les variables globales
- une pour la pile (stack)
- une pour le tas (heap) qui sert pour tout ce qui est allocation dynamique de mémoire.
oui, mais ça passe normalement par la pile.la l'instruction (return data) returné la valeur de data a la variable read_eeprom
A+
par ce que y'a beaucoup des personnes qui vient me dire d'aller apprendre le français avant de parler de langage C
non et je répète mon exemple, dans le langage C l'instruction return a un autre sense que les autres langage comme l'assembleur, le return data; dans le C n'est que (read_eeprom = data
En C, tu as 3 zones mémoire pour les variables: cet phrase est faux tu ne peux pas dire qu'en C car le C ou d'autre langage na rien avoir avec les memoire peut étre tu veux dire (en ce composent, tu as 3 zones mémoire pour les variables) et le langage lui qui est adapté pour le faire fonction avec telle ou telle composentC'est l'adresse de la prochaine instruction de la fonction appelante suivant l'appel de la fonction appelée qui est mémorisée dans la pile.
Dernière modification par LABTOOL48 ; 16/09/2011 à 23h17.
Mais de quoi tu parles? Quel rapport avec une eeprom? J'ai l'impression que tu me parles de petit µC genre PIC qui possèdent une pile ridicule.read_eeprom = data
Moi je te parle du comportement du C en général. Avec les µprocesseurs actuels qui possèdent de nombreux registres, les arguments peuvent effectivement passer par eux si la quantité de données n'est pas trop importante.
Mais en cas de récursivité, comment veux-tu faire autrement que de passer les arguments par la pile?
Mais encore une fois de quoi tu parles? Ces 3 zones sont dans la ram. Point barre. On s'en moque de savoir si c'est stocké dans tel ou tel composant. La ram, c'est la ram.cet phrase est faux tu ne peux pas dire qu'en C car le C ou d'autre langage na rien avoir avec les mémoire peut étre tu veux dire (en ce composent, tu as 3 zones mémoire pour les variables) et le langage lui qui est adapté pour le faire fonction avec telle ou telle composent
Pour les variables locales, c'est bien stocké dans la pile et pour les variables dynamique, une table d'allocation est tenue à jour afin de savoir ou il reste de la place dans le tas.
A+
Un peu de lecture ...
http://www.maxi-pedia.com/what+is+heap+and+stack
A+
non merci j'ai plus le temps pour lecteur
le pic ou d'autres µC \cpu tous possèdent une pile, Point barreMais de quoi tu parles? Quel rapport avec une eeprom? J'ai l'impression que tu me parles de petit µC genre PIC qui possèdent une pile ridicule.
les nombreux registres ou la quantité de données et les arguments tous ce passe entre eux et rien ne ce place dans la pileMoi je te parle du comportement du C en général. Avec les µprocesseurs actuels qui possèdent de nombreux registres, les arguments peuvent effectivement passer par eux si la quantité de données n'est pas trop importante.
Mais en cas de récursivité, comment veux-tu faire autrement que de passer les arguments par la pile?
La ram, c'est la ram . Point barre alors pas besoin de parler de tes 3 zonesMais encore une fois de quoi tu parles? Ces 3 zones sont dans la ram. Point barre. On s'en moque de savoir si c'est stocké dans tel ou tel composant. La ram, c'est la ram.
les variable globale locale ou dynamique tous sont avec ses proprs adresses ? et on le sais maintenant que tu n'utilise pas les pic et que tu as cpu mais quand meme ton cpu sophistiqué lol ne s'exécuter pas dix instructions a la fois ? et to cpu a un PC comme tous le monde n'est-ce pas ? alors dit nous que fait ton cpu quand le PC pointe sur tes variable locale il le traite ou il la sauvegade dans la pile ? pour moi non il ne la sauvegarde pas tous simplent par ce que la variable locale ou autres ces sont pas des instructions pour modifier les OPCODE pour indiquer au cpu de sauvegader le PC dans la pile et nous n'avous que les instructions de call qui modifient ces OPCODE et pour les variable locale pour moi quand le PC pointe sur sont adresse il va la traiter "copier" ou "coller" de sont contenu et puis on va a l'instruction suivante et pas de sauver sont adresse dans la pile ,et on peut revenir a la meme variable locale une autre fois mais via l'appelle de sa fonction c'est la seule moyent que je connaisPour les variables locales, c'est bien stocké dans la pile et pour les variables dynamique, une table d'allocation est tenue à jour afin de savoir ou il reste de la place dans le tas.
Dernière modification par JPL ; 17/09/2011 à 13h26. Motif: Modification de balises
J'adore ton ouverture d'esprit. Je fais référence à des articles qui montrent que tu as tort, mais comme ça ne t'arrange pas tu refuses de les lire.
Evidemment si tu te réfères aux pic midrange du type 16Fxxx, ceux-ci possèdent une minuscule pile qui n'est pas en RAM mais intégrée en hard dans le µcontrôleur. C'est une très forte limitation pour leur utilisation en C. Il est impossible d'effectuer un algorithme récursif par exemple.
Ce dont je parle, c'est des µprocesseurs "normaux", donc des 99,99% des cas.
Non, tous (à part les petits µContrôleurs chez microchip) possèdent un pointeur de pile qui doit pointer sur la RAM.le pic ou d'autres µC \cpu tous possèdent une pile, Point barre
Prouve-le.les nombreux registres ou la quantité de données et les arguments tous ce passe entre eux et rien ne ce place dans la pile
Et pourtant c'est comme ça avec quasiment tous les µprocesseurs. Et j'en ai programmé un paquet.La ram, c'est la ram . Point barre alors pas besoin de parler de tes 3 zones
A+
Dernière modification par Jack ; 17/09/2011 à 09h09.
Voilà un extrait de la doc d'un PIC24.
Tu constateras donc que microchip a fini par reconnaitre qu'une pile doit se trouver en RAM (A condition bien sûr de lire ma pièce jointe).
Pièce jointe 158549
A+
Dernière modification par Jack ; 17/09/2011 à 09h20.
je ne veux pas lire les choses qui ne m'intéresse pas , j'ai mon probleme de pic16f pour envoye des trame avec uart tu me veut que je le laisse et d'aller pour lire le pic24 !J'adore ton ouverture d'esprit. Je fais référence à des articles qui montrent que tu as tort, mais comme ça ne t'arrange pas tu refuses de les lire.
dans le cas de mon pic16f, la pile et la ram plus le flash et tous intégrée en hard dans le µcontrôleurEvidemment si tu te réfères aux pic midrange du type 16Fxxx, ceux-ci possèdent une minuscule pile qui n'est pas en RAM mais intégrée en hard dans le µcontrôleur. C'est une très forte limitation pour leur utilisation en C. Il est impossible d'effectuer un algorithme récursif par exemple.
d'après tous cette info et tu veux qu'on nous mettre les variables locale dans la pile ?C'est une très forte limitation pour leur utilisation en C. Il est impossible d'effectuer un algorithme récursif par exemple.
le pointeur le pic pointe partou dans la memoire de picEvidemment si tu te réfères aux pic midrange du type 16Fxxx, ceux-ci possèdent une minuscule pile qui n'est pas en RAM mais intégrée en hard dans le µcontrôleur. C'est une très forte limitation pour leur utilisation en C. Il est impossible d'effectuer un algorithme récursif par exemple.
Le problème est que tu ne nous parles que des pics 16F qui constitue un cas très particulier alors que moi je parle du cas général.
Je te rappelle la question d'origine:
Je pense que ma réponse est plus pertinente et plus documentée. Ca ne veut pas dire que tu as tort, mais tu ne répond qu'à un cas particulier, ce qui n'est pas l'objectif premier.Bonjour
J’aimerais savoir ce que fait l’ordinateur lorsqu’on envoie (en C) des arguments à une fonction.
Va t’il tous les copier dans un certain endroit de la mémoire ?
Ou va t’il tout simplement s’en servir dans la fonction, sans rien copier ?
Merci
A+
non ça c'est toi qui ne nous parle que de pic, moi j'ai plus parlé de pic que pour répond a la question posé par toi quand toi viens nous dire les pic possèdent une minuscule pile qui n'est pas en RAM mais intégrée en hard dans le µcontrôleur, qu'est ce que tu m'attende de te dire ? de te parler de TMS par exemple ? ,vas relire s'il tu plais tes poste et voir ton cas général que tu as nous parlerCode:Le problème est que tu ne nous parles que des pics 16F qui constitue un cas très particulier alors que moi je parle du cas général.
pour moi, pour les paramères de la fonction ces sont des variable de type int ou char (en général ) et pour l'acces a un paramètre d'une fonction il faut connaitre sont adresse et donc au moment de l'exécution de la fonction appelé les adresses de ses paramètres passons dans le PC et c'est la que l'ordinateur initial ces variable de paramètres et le PC continue de s'incrémenter pour pointer a la premier instruction de la fonction appelé et de traiter sesparamétres jusqu'au la fineCode:Bonjour J’aimerais savoir ce que fait l’ordinateur lorsqu’on envoie (en C) des arguments à une fonction. Va t’il tous les copier dans un certain endroit de la mémoire ? Ou va t’il tout simplement s’en servir dans la fonction, sans rien copier ? Merci
la j'ai réponde pour le cas de la fonction mai() de l'appwin parce que tu nous parle de "l'ordinateur"
On se demande vraiment à quoi peuvent servir les instructions push et pop qu'on retrouve sur la majorité des micros un tant soit peu performant.
Effectivement il y a aussi (encore) des micro avec une pile interne de quelques niveaux seulement: des micro 4bit NEC (78...), des PIC bas de gamme, et à une époque révolue le am2910 (de mémoire) des micros en tranche de la famille AMD am2900 (microprocesseur en tranche de 4 bits, vous voulez un 32 bits, mettez 8 tranches, si, si, je ne déconne pas... ).
Si vraiment tu n'as pas de temps, pourquoi répondre à un sujet qui dormait tranquillement depuis 1 mois presque.
Il faut prendre le temps d'écouter les autres, de lire les autres docs, ça permet d'évoluer de devenir humble (et donc d'être moins arrogant...)
Jusqu'ici tout va bien...
Pour ma part, tant de mauvaise foi et de méconnaissances me fatiguent.
Au lecteur de se faire une opinion.
Pas A+
On se demande vraiment à quoi peuvent servir les instructions push et pop qu'on retrouve sur la majorité des micros un tant soit peu performant.
Effectivement il y a aussi (encore) des micro avec une pile interne de quelques niveaux seulement: des micro 4bit NEC (78...), des PIC bas de gamme, et à une époque révolue le am2910 (de mémoire) des micros en tranche de la famille AMD am2900 (microprocesseur en tranche de 4 bits, vous voulez un 32 bits, mettez 8 tranches, si, si, je ne déconne pas... ).
Si vraiment tu n'as pas de temps, pourquoi répondre à un sujet qui dormait tranquillement depuis 1 mois presque.
Il faut prendre le temps d'écouter les autres, de lire les autres docs, ça permet d'évoluer de devenir humble (et donc d'être moins arrogant...je ne peux plus te dire le contraire parce que tu as raison et ta réponse est (logique) mais est-ce que tu ne vois pas que ta réponse trop loin a ce que j'ai parlé moi ? pile\tableaux\paramètres\valeu r de return moi la j'ai parlé de (variables) ni plus ni moins en général ces sont que des cases placé en mémoire, 4 ou 8\16\ ou 32 ces n'est pas notre problème, tous ces variables ne provoquent pas le cpu pour d'aller placer le contenu de PC au Pile, c'est pas du tout comme le cas d'instructions push et pop que je ne les connais pas encors et quand je parlé de "call" pas forcement parlé de pic ni pas du tout dire aussi qu'il n'y a pas d'autres instructions dans d'autres micro\cpu que je ne connais pas, mais je vais te réponde logiquement et en général, si tes push et pop contient un code d'opération qui permettre au cpu de placer un tableau ou variable en pile la je te dire "oui" mais ce qui est n'est pas logique pour moi, pour quoi en déclare un tableau ou variables qui occupent quel que cases mémoire et puis les en piler ? , tu me dis peut étres pour le traitement ?, OK en "C" par exemple pour faire copie\coller un contenu d'un tabeau a l'autre on utilisent soit une fonction faite pour ça ou une simple boucle "for()" et dans le cas for() si la boucle tourne cent fois par exemple l'adrasse de ces tableaux elle passe cent fois au PC, et comme nous n'avons qu'un seul PC pas seulement le pic mais en général dans tous les micro\cpu donc les données ne se traite que case par case et meme cas avec les variable si le nom d'une variable se répète dans le code "C" son adresse se repasse par PC et nous n'avons plus besoin dans le cas ci de sauvé son adresse dans la pile , on ne sauve pas dans la pile en général que si on a besoin de return dans tous am2910\NEC\ PIC sauf si vous parle a d'autres mémoire que la pile comme la mémoire cash par exemple merci et désolé pour la langueOn se demande vraiment à quoi peuvent servir les instructions push et pop qu'on retrouve sur la majorité des micros un tant soit peu performant.
Bonjour,
En C, les variables globales ou statiques ont effectivement une adresse définie une fois pour toute au lancement du programme.
Les variables automatiques (cas général des variables locales) sont forcément empilées, sinon une fonction ne pourrait pas être récursive, ce qui est bien utile dans certains cas (parcours d'arbre, algo de ray-tracing, ...).
non : la norme du C est que toutes les variables automatiques soient empilées.
Tu as sûrement raison dans le cas de micro-controleurs que je ne connais pas, mais le C a été conçu pour programmer un système d'exploitation (UNIX) dont le fonctionnement est fondamentalement récursif (un process crée un process qui crée un process ...).
C'est ce que j'ai vainement tenté de démontrer.
Là par contre je ne suis pas d'accord avec toi sur l'histoire de processus. Il n'y a rien de récursif là-dedans puisque si c'était le cas il faudrait terminer les processus dans l'ordre inverse de leur création (remontée de la pile) alors qu'un processus père peut être tué sans que celà entraine systématiquement l'arrêt de ses descendants.un système d'exploitation (UNIX) dont le fonctionnement est fondamentalement récursif (un process crée un process qui crée un process ...).
A+
je suis daccord avec toiCode:En C, les variables globales ou statiques ont effectivement une adresse définie une fois pour toute au lancement du programme. Tu as sûrement raison dans le cas de micro-controleurs que je ne connais pas, mais le C a été conçu pour programmer un système d'exploitation (UNIX) dont le fonctionnement est fondamentalement récursif (un process crée un process qui crée un process ...).[/QUOTE]
juste pour l'info et rien d'autre je te montre un petit code en C pour nous montre les variables auto et qui sont les variables locales pour toi dans ce code et la raison pour " la norme du C est que toutes les variables automatiques soient empilées"Code:Les variables automatiques (cas général des variables locales) sont forcément empilées, sinon une fonction ne pourrait pas être récursive, ce qui est bien utile dans certains cas (parcours d'arbre, algo de ray-tracing, ...). non : la norme du C est que toutes les variables automatiques soient empilées.
je suis vraiment coincé entre si les Buffers sont des variables locales "Les variables automatiques (cas général des variables locales) sont forcément empilées" ou sinon sinon une fonction ne pourrait pas être récursiveCode:void fonction(void) { int i; cher Buffer1[200000]; cher Buffer2[200000]; for(i = 0;i < 1999999;i++) { Buffer2[i] = Buffer1[i]; } }
C'est assez curieux comme faute, naturellement il aurait fallu écrirevoid fonction(void)
{
int i;
cher Buffer1[200000];
cher Buffer2[200000];
for(i = 0;i < 1999999;i++)
{
Buffer2[i] = Buffer1[i];
}
}
De toute façon, votre code ne fait pas grand-chose, puisque Buffer1 n'est pas renseigné.void fonction(void)
{
int i;
cher Buffer1[200000]; // cher (au lieu de char) est une faute de frappe
cher Buffer2[200000];
for(i = 0;i < 200000;i++) // ou alors i <= 199999
{
Buffer2[i] = Buffer1[i];
}
}
Mais la vraie question que je me pose : Pourquoi en voulez-vous à la pile. On peut dire que sauf exception, toutes le variables sont empilées. Cette question ne vaut pas le coup d'être discutée.
Il y a peut-être un point qui vous a échappé : Lorsque vous déclarez Buffer1[20]. En fait vous déclarez un pointeur sur un tableau qui est le premier élément du tableau. Naturellement ce ne sont pas les 400000 char qui sont empilés, mais seulement les 2 pointeurs.
On aurait pu écrire
char *ptr1=Buffer1[0];
char *ptr2=Buffer2[0];
for(i = 0;i < 200000;i++)
{
ptr1++ = ptr2++;
}
C'est sensé faire quoi ce code? Copier le contenu du 1er tableau dans le second? C'est pas gagné.
Bonjour Jack,
Naturellement, il y a fort peu de chances que la machine arrive à trouver un espace mémoire de 200000 caractère (2 fois).
J'essayais seulement d'expliquer que la gestion des tableaux en C se faisait par les pointeurs.
Probablement dans un souci d'écriture j'aurais du répéter la déclaration des 2 tableaux, voila en fait ce que j'aurais dû écrire
Pardon pour la faute de syntaxeCode:void fonction(void) { int i; char Buffer1[20]; char Buffer2[20]; char *ptr1; ptr1= Buffer1; char *ptr2; ptr2 = Buffer2; for(i = 0;i < 20;i++) { ptr1++ = ptr2++; } }
En fait ce qui me gênait c'était les erreurs d'adresse et de valeurs pointées:
A+Code:char *ptr1=&Buffer1[0]; // ou plus simplement char* ptr1 = Buffer1; char *ptr2=&Buffer2[0]; // idem for(i = 0;i < 200000;i++) { *ptr1++ = *ptr2++; }
Oups !
Effectivement ...
Je crois que tu te trompe.
Toutes les variables automatiques sont empilées, y compris le contenu des tableaux.
Expérience (en C ANSI) :
produit le résultat suivant :Code:#include<stdio.h> #include<string.h> void fonction (void) { static char compteur_appels; static char tableau1 [10]; char tableau2 [10]; char identifiant; compteur_appels++; identifiant = compteur_appels; // pour reconnaître les deux appels à fonction() printf ("1. identifiant %d\n", identifiant); printf ("1. tableau1[0] = %d\ttableau1[1] = %d\tadresse = %p\n", tableau1[0], tableau1[1], tableau1); printf ("1. tableau2[0] = %d\ttableau2[1] = %d\tadresse = %p\n\n", tableau2[0], tableau2[1], tableau2); memset (tableau1, identifiant, sizeof tableau1); memset (tableau2, identifiant, sizeof tableau2); printf ("2. identifiant %d\n", identifiant); printf ("2. tableau1[0] = %d\ttableau1[1] = %d\tadresse = %p\n", tableau1[0], tableau1[1], tableau1); printf ("2. tableau2[0] = %d\ttableau2[1] = %d\tadresse = %p\n\n", tableau2[0], tableau2[1], tableau2); if (compteur_appels < 2) fonction(); //appel récursif printf ("3. identifiant %d\n", identifiant); printf ("3. tableau1[0] = %d\ttableau1[1] = %d\tadresse = %p\n", tableau1[0], tableau1[1], tableau1); printf ("3. tableau2[0] = %d\ttableau2[1] = %d\tadresse = %p\n\n", tableau2[0], tableau2[1], tableau2); } int main (int argc, char ** argv) { fonction(); }Au début, les tableaux ne sont pas initialisés. Le tableau static est initialisé à 0 et le tableau auto contient n'importe quoi (-1)1. identifiant 1
1. tableau1[0] = 0 tableau1[1] = 0 adresse = 00406A30
1. tableau2[0] = -1 tableau2[1] = -1 adresse = 0012FF78
2. identifiant 1
2. tableau1[0] = 1 tableau1[1] = 1 adresse = 00406A30
2. tableau2[0] = 1 tableau2[1] = 1 adresse = 0012FF78
1. identifiant 2
1. tableau1[0] = 1 tableau1[1] = 1 adresse = 00406A30
1. tableau2[0] = -84 tableau2[1] = 96 adresse = 0012FF64
2. identifiant 2
2. tableau1[0] = 2 tableau1[1] = 2 adresse = 00406A30
2. tableau2[0] = 2 tableau2[1] = 2 adresse = 0012FF64
3. identifiant 2
3. tableau1[0] = 2 tableau1[1] = 2 adresse = 00406A30
3. tableau2[0] = 2 tableau2[1] = 2 adresse = 0012FF64
3. identifiant 1
3. tableau1[0] = 2 tableau1[1] = 2 adresse = 00406A30
3. tableau2[0] = 1 tableau2[1] = 1 adresse = 0012FF78
Je remplis les deux tableaux de 1
Deuxième appel à la fonction :
Le tableau static a la même adresse et contient toujours les 1
Le tableau auto a changé d'adresse et contient du coup n'importe quoi (-84, 96, ...)
Je remplis les tableaux avec des 2
Au retour de la fonction, les variables sont dépilées, et je constate que le tableau static contient toujours les 2, mais que le tableau auto a repris l'adresse du premier appel et contient donc des 1
Le même programme en mettant :
plante sauvagement (dépassement de la pile)Code:static char tableau1 [2000000]; char tableau2 [2000000];
Le même, en déclarant les deux tableaux en static fonctionne, parce que même mon vieil ordi pourri a plus de 4Mo de RAM
Raison pour laquelle il ne faut jamais déclarer en auto les trop gros paquets de données.
Effectivement, c'est seulement au passage de paramètres (sujet initial) qu'on ne passe que le pointeur d'un tableau (sur la pile bien sûr...).
Jusqu'ici tout va bien...
