Que fait l’ordinateur lors d’envoi d’arguments à une fonction ?

Dlzlogic · 16/09/2011 - 12h49

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.

LABTOOL48 · 16/09/2011 - 14h27

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

Code:

unsigned char read_eeprom(int adresse )
{
    uchar data;
    registreadresse = adresse ; // exemple l'envois de l'adresse 
    x instruction
    x instruction
   return data;
}

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 = 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()

Code:

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)

et c'est la meme chose pour les paramètres d'entrer exemple

Code:

 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;

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 lire

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 )

LABTOOL48 · 16/09/2011 - 15h10

Envoyé par Jack

Contrairement à ce que tu affirmes l'adresse de la fonction appelante n'est pas stockée dans la pile. C'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.

la tu as raison

**JPL** · 16/09/2011 - 15h11

Tu te débrouilles assez bien en français.

**Jack** · 16/09/2011 - 15h45

pour les paramètres ces sont les variables char ou int ces placer dans la ram exemple

Oui c'est normal puisque la pile est forcément en RAM.

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.

la l'instruction (return data) returné la valeur de data a la variable read_eeprom

oui, mais ça passe normalement par la pile.

A+

LABTOOL48 · 16/09/2011 - 21h09

Envoyé par JPL

Tu te débrouilles assez bien en français.

par ce que y'a beaucoup des personnes qui vient me dire d'aller apprendre le français avant de parler de langage C

LABTOOL48 · 16/09/2011 - 22h14

Envoyé par Jack

oui, mais ça passe normalement par la pile.

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

car ici nous n'avons plus d'appelle aux fonctions le PC pointe sur l'adresse de la variable pour copier le data dedans c'est tous et nous n'avons plus besoin de sauvegarder le PC dans la pile le role de la fonction return s'est terminé ici, et on va maintenant réstorer le PC comme tu as dis exetement

C'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.

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 composent

**Jack** · 16/09/2011 - 22h54

read_eeprom = data

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.
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?

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

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.

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+

**Jack** · 16/09/2011 - 22h58

Un peu de lecture ...
http://www.maxi-pedia.com/what+is+heap+and+stack

A+

**Jack** · 16/09/2011 - 23h05

http://en.wikipedia.org/wiki/C_%28pr...ory_management

LABTOOL48 · 17/09/2011 - 00h13

Envoyé par Jack

non merci j'ai plus le temps pour lecteur

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.

le pic ou d'autres µC \cpu tous possèdent une pile, Point barre

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?

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

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.

La ram, c'est la ram . Point barre alors pas besoin de parler de tes 3 zones

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.

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 connais

**Jack** · 17/09/2011 - 08h07

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.

le pic ou d'autres µC \cpu tous possèdent une pile, Point barre

Non, tous (à part les petits µContrôleurs chez microchip) possèdent un pointeur de pile qui doit pointer sur la RAM.

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

Prouve-le.

La ram, c'est la ram . Point barre alors pas besoin de parler de tes 3 zones

Et pourtant c'est comme ça avec quasiment tous les µprocesseurs. Et j'en ai programmé un paquet.

A+

**Jack** · 17/09/2011 - 08h18

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).

PIC24.jpg

A+

LABTOOL48 · 17/09/2011 - 09h27

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.

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 !

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.

dans le cas de mon pic16f, la pile et la ram plus le flash et tous 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 ?

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.

le pointeur le pic pointe partou dans la memoire de pic

**Jack** · 17/09/2011 - 11h18

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:

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

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.

A+