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
le C ne sait transmettre des paramètres que par valeur. Les paramètres sont copiés et stockés dans la pile du microprocesseur pour le processus en cours.
Ces arguments sont dépilés dans la fonction et si cette fonction renvoie un résultat, celui-ci est empilé. L'adresse de retour est replacée au 1er emplacement libre, ce qui permet de revenir à la fonction appelante.
A+
ok
Si j'envoie donc des paramètres en trop à une fonction, l'ordinateur mettra plus de temps de calcul ?
Par exemple si j'envoie un tableau :
int tab[2000] ;
et que seul les 20 premières cases sont utilisées par la fonction, l'ordinateur mettra 100 fois plus de temps (si on néglige les calculs utiles dans la fonction), que si je sépare en deux tableaux !?
Ou peux je compter sur mon bon compilateur, qu'il trie ce qui est utilisé et ce qui ne l'est pas ?
le compilateur n'a aucune idée de ce que l'exécution de ton code va produire. Imagine que tu accèdes à une case du tableau en donnant l'indice à l'aide d'une variable, par exemple x = tab[i];
le compilateur ne peut pas connaitre quelles valeurs pourra prendre la variable i.
Pour l'exemple que tu donnes, quand on passe un tableau en paramètre, la variable identifiant ce tableau, donc tab dans ton exemple, contient en fait l'adresse du 1er octet du tableau. Le tableau n'est donc pas copié dans la pile, pour des raisons de place mémoire principalement et accessoirement de temps pour empiler et dépiler les données du tableau.
A+
comme tu ne peux pas envoyer le contenu, il est fort probable que tu fasses:
int tab[2000];
remplissage de tab...
fonctionquiabesoinsde20(tab);
et là tu envoie l'adresse du tableau, quelle que soit la taille du tableau.
et dans ta fonction, tu bosses sur le tableau d'origine.
si tu veux bosser sur une copie, il faut la faire à la main avant d'appeler la fonction on dans la fonction même (ex copie partielle avant d'appeler):
int tab[2000];
int copietab[20]
remplissage de tab...
memcpy(copietab, tab, 20*sizeof(int));
fonctionquiabesoinsde20(copiet ab);
Jusqu'ici tout va bien...
j'ajouterais que lorsqu'on passe un tableau en paramètre, il est souvent nécessaire de passer également la taille du tableau car la fonction, pour être suffisamment générique, doit pouvoir travailler sur des tableaux de taille variable.
A+
Bonjour,
J'ai l'impression qu'AmigaOS a surtout posé la question dans le sens de la rapidité. A mon avis ce n'est pas vraiment comme ça que se pose le problème.
Par principe le C ne peut pas modifier la valeur d'une variable dans une fonction.
Quand on passe un tableau en paramètre, ce n'est pas le tableau la variable mais la position mémoire de son premier élément (pointeur ou référence). Pour bien visualiser cela, à mon avis il vaut mieux faire des essais avec une chaine de caractères (cad un tableau de caractères).
Ce mécanisme est souvent considéré comme l'un des points les plus difficiles à comprendre dans le langage C.
Dans la fonction, on peut modifier tab[0], qui est le premier caractère. Sa valeur sera modifiée, mais pas son adresse.
Au point de vue syntaxe, ce sera :
void LaFonction (int tab[])
{
... traitement
}
Moi, je préfère écrire
void LaFonction (int *tab)
Dans le programme
int tab[1000];
// écriture éventuelle de tab
LaFonction(tab);
Si vous avez le moindre doute, montrez-nous votre code.
Oui ma question était dans le sens de la rapidité.
Mais j'ai compris, vous m'avez aidé.
Merci
C'est plus ou moin inexacte avec un compilateur C/C++ traditionnel, en C et dérivés en général, si la fonction renvoie un résultat il est écrit dans le registre CPU EAX.Envoyé par Jack
Mais celà peut aussi dépendre de la convention employé par les deux partis.
ca c'est pour une architecture intel ou compatible et pour un renvoi de paramètre simple. ca permet effectivement de gagner du temps.
Mais d'une manière générale, et pour des données plus complexes, telle un estructure, il me semble que c'est bien la pile qui est utilisée.
Mais je ne suis pas pointu sur le sujet et je suis très intéressé par ds articles de référence.
A+
J'avoue que je ne suis jamais posé la question de savoir où et par quel chemin transitait la valeur renvoyée par une fonction.
Mais je crois bien que ça ne dépend pas du type de ce qui est renvoyé.
Cependant, ce problème n'est pas à négliger, surtout dans le cas d'appels récursifs, le genre de truc qui fait déborder une pile.
En effet j'ai oublié de préciser que cela se cantonne a la famille x86 compatible (pour la référence au registre eax), en ce qui concerne les structures oui elles sont belles est transmises par la pile, bien qu'elles puissent êtres aussi transmises par le registre EAX ou équivalent sur une architecture différente, en passage par référence (eg liste chainée, ...).
Aprés comme je l'est dit cela dépend de la convention.
En effet étant donné que chaque entités variable manipulé par des fonctions posséde une adresse donc sa ne dépend pas du type, c'est modulé en fonction de la convention de passage de paramètres (ThisCall, stdcall, ...) et non en fonction des types.
J'ai commencé par programmer des µprocesseurs, le Z80 entre autres et en asm bien sur, puis je suis passé aux langages évolués grâce au turbo pascal. Ca tournait sur un APPLE II avec une carte Z80 sous CP/M. Pour te dire si ça remonte à loin.
A l'époque, l'optimisation n'était pas un vain mot et j'ai régulièrement écrit des fonctions en asm qu'il fallait interfacer avec le pascal. Il fallait alors absolument connaitre les conventions de passage des arguments.
Les concepteurs du C n'ont pas été très sympa d'inverser l'ordre de passage de ces argument. C'est pourquoi il a été prévu un mot réservé pour forcer un passage en convention pascal dans du source en C.
A+
En fait, en C, les paramètres sont passés... point barre.
Ensuite le comment dépend du compilo.
Il y a plusieurs points:
qui "dépile" au retour?
où est-ce qu'on met tout ça?
Par exemple pour des processeurs ayant une pile d'appel très limitée, on peut carrément avoir en parallèle une pile de données plus confortable.
D'un autre coté, certains processeurs disposent d'une flopée de registres dont certains sont alors dédiés au passage de paramètres (ainsi qu'au retour quand possible).
Idem, on peut avoir une pile spécifique pour les appels asynchrones (déclenchés par une interruption système (voir sigaction et sigaltstack)).
On peut aussi un peu forcer la façon de faire à l'aide de directives pas vraiment standard... mais qui permettent de se coller à d'autres langages.
Jusqu'ici tout va bien...
point barre, c'est vite dit. Comme tu l'expliques par ailleurs, pour l'interfaçage à d'autres langages, il faut faire attention aux conventions. C'est le cas quand tu veux faire appel à des fonctions qui ont été écrites en pascal par exemple.En fait, en C, les paramètres sont passés... point barre.
A+
Ce que je voulais surtout dire, c'est qu'il n'y a pas de règle absolue...
Jusqu'ici tout va bien...
En tous cas s'il y en a une qui se démocratise depuis un moment, c' est la thiscall avec le passage de l'adresse de base de la structure dans ECX pour les x86/x64 et notions équivalente pour les autres.
La tendance actuelle, et même chez microsoft est la réécriture des API existante employant (stdcall, pascal,....) en librairie orienté objet pour avec le thiscall pour le paradigme objet (POO).
il y a aussi l'appel fastcall en C++ builder.
A+
Bonjour,
C'est tout de même très amusant. On peut lire des affirmations d'informaticiens disant que maintenant, on n'a plus besoin de se préoccuper d'espace mémoire ou de temps d'exécution, et à l'opposé il y en a encore, heureusement, qui y attachent de l'importance, jusque dans des détails qui sont plus du domaine du hard que du soft.
Sur un autre forum, j'ai dit que pour un grand nombre de test, l'utilisation de switch était plus rapide de celle du if ... else if ...Ca a provoqué un débat assez intéressant.
Je ne cherche en aucun cas à relancer ce sujet. L'explication est simple, un switch sera traité comme un saut ordinaire, alors que le if ne peut être traité au moment de l'exécution que comme un saut conditionnel. Etant donné le mode de traitement par évènement, cette notion peut devenir importante. Si en plus, on utilise des techniques de hachage, alors on arrive à des logiciels performants.
A moin n'avoir pas correctement interprété ton commentaire, mais sauf illogisme un switch est une instruction qui va comparer le contenus d'une variable avec une constante et en fonction de l'activation du bit ZF du registre de flags du CPU (eg EFLAGS sous x86/x64), dans le cas d'une comparaison entière ou de la sortie d'une fonction de comparaison de chaines dans un langage évolué, alors il saute ou non le cas échéant dans le code.Bonjour,
L'explication est simple, un switch sera traité comme un saut ordinaire, alors que le if ne peut être traité au moment de l'exécution que comme un saut conditionnel. Etant donné le mode de traitement par évènement, cette notion peut devenir importante. Si en plus, on utilise des techniques de hachage, alors on arrive à des logiciels performants.
Ainsi c'est une instruction de saut conditionnel à l'instar du IF.
On parle bien de la même chose ? :
switch(x) {
case 0xA:
do_something();
break;
....
default:
}
Oui, on parle de la même chose.
Je passe le cas où le nombre de tests est assez limité, disons une dizaine, mais du cas ou il y a plusieurs dizaines de case.
Les essais sont sans contestation possible et un spécialiste du code généré a même déterminé le nombre de tests pour lequel la probabilité était du même ordre.
Il n'est pas vrai qu'une instruction switch est une instruction qui va comparer le contenus d'une variable avec une constante. Lors de la compilation et de la génération du code les adresses de branchement sont prévues et un accès direct est codé.
En tout cas il est très facile de faire un petit code qui vérifie cela.
Il est vrai que j'ai un peu de mal à expliquer cela sur le plans strictement technique, mais pour s'en convaincre le mieux est d'essayer.
Désolé mais je le traduis comme celà un switch, ce que tu dis est incorrecte,
dans un switch il y a un choix de branchement dans un ou plusieurs case en fonction de la présence de break, c'est invraisemblable ce que tu avance,
un branchement selon des valeurs implique nécessairement un calcul de comparaison.
[SEGMENT .text]
....
//On arrive au switch
lea ebx, ma_var
mov eax, [ss:ebx]
cmp eax, 0xA
je _0xA_status
jmp _end_switch ; ici l'équivalent du break
cmp eax, 0xB
je _0xB_status
push -1 //Ici le default
push title
push msg
...
call user32.MessageBoxA
_end_switch:
...
[SEGMENT .data]
ma_var dd ?
title db "Default case"
msg db "choix par defaut"
Bonsoir,
Je ne vois pas le rapport avec l'instruction break, qui n'est qu'une instruction de sortie. Il s'agit ici de branchement et non de sortie.
La case "default" n'entre pas dans la discussion, puisque dans le contexte concerné, tout les branchements ont été prévus. La case default n'est qu'une sécurité.
Moi, je veux bien qu'on dise que ce que j'avance est invraisemblable, ça ne change rien au fait que j'ai décrit et expliqué et qu'il est très facile de vérifier.
Evidemment, je ne peut rien dire à propos d'un code généré, la seule chose qui m'intéresse et que je vérifie est le temps d'exécution.
Surtout ne me dites pas qu'un case doit être terminé par un break, ou que la case "default" doit être présente.
Enfin, avez- fait un bout de code qui compare les temps d'exécution ?
Le switch quand il y a assez de cas possibles et calculables (genre des nombres qui se suivent), on peut faire un test de borne (si dans la plage des valeurs possibles) suivi d'un saut calculé avec un tableau d'adresses (même un vieux compilo C sur 6502 me faisait ça...).
Donc chaque cas de switch n'impose pas un test de valeur.
Ensuite, le break, c'est un "goto plus loin" un peu déguisé...
Jusqu'ici tout va bien...
Nostalgie .. j'ai bien connu l'époque où la technique du chausse-pied n'était pas un vain mot, et que l'économie de place (mémoire et/ou périphérique) était vitale
On trouve des chercheurs qui cherchent ; on cherche des chercheurs qui trouvent !
Bonjour,
Manifestement entre développeurs de la même génération, il nous reste les mêmes réflex. Je me souviens du programme de dessin que j'ai fait pour mes enfants sur ZX81.
C'est vrai : 1k de mémoire pour tout faire !
On trouve des chercheurs qui cherchent ; on cherche des chercheurs qui trouvent !
bonjour
la pile na rien avoir avec des tableaux ni de paraméres d'entrer ni la valeur de reture rien de tous ça passe dans la pile que l'adresse de lafonction appelante
et désolé pour la langue je connais pas bien le français
D'accord, mais ce nest pas très clair ce que tu dis.
Si j'ai bien compris, tu veux dire que les paramètres d'une fonction ne passent pas par la pile. C'est faux, les paramètres sont des varibles locales donc sont stockées normalement dans la pile du processeur (à moins d'optimisation du compilateur ou passage explicite par les registre, mais c'est une exception).
La valeur de retour passe normalement aussi par la pile.
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.
A
