Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou
maitrise. Ou les bases de l'Assembleur.
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou
maitrise. Ou les bases de l'Assembleur.
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou
maitrise. Ou les bases de l'Assembleur.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
"M.B." writes:Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
Tu me doit un trollometre. Le mien vient d'exploser.
"M.B." <mbinder@magicnet.com> writes:
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
Tu me doit un trollometre. Le mien vient d'exploser.
"M.B." writes:Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
Tu me doit un trollometre. Le mien vient d'exploser.
"Jean-Marc Bourguet" a écrit dans le message news:"M.B." writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai
l'impression que tu va me donner une architecture typique des micro
des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann. Rien de
fondamentalement neuf depuis.
La connaissance du fonctionnement de la pile me parait
indispensable pour comprendre les differents types de passage
d'arguments.
Le passage des arguments est une fonctionalite abstraite definie par
le langage, la maniere de l'implementer sur ton architecture n'a
aucune importance. Et je ne vois pas l'utilite d'une pile pour
passer les arguments, on essaie plutot meme de l'eviter. (Je vois
l'utilite de la pile pour garder un contexte quand des appels
recursifs sont possibles, mais tous les langages n'autorisent pas le
recursivite).
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a
assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple
possible d'ordinateur. Son utilite pour apprendre a bien programmer
me semble douteuse. Elle peut avoir l'effet nocif de laisser penser
que la maniere evidente d'implementer quelquechose dessus est la
seule possible.Et il est pour moi evident que mieux on connait le fonctionnement
interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un
exercice qui consiste a batir des abstractions sur d'autres
abstractions. Et quand on programme en C++, les abstractions de plus
bas niveaux utilisees sont celles fournies par le langage C++, pas
celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait. On ne
peut pas trouver plus concret.A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ET cela manque a bien des programmeurs.
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
pxboex0apg4.fsf@news.bourguet.org...
"M.B." <mbinder@magicnet.com> writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai
l'impression que tu va me donner une architecture typique des micro
des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann. Rien de
fondamentalement neuf depuis.
La connaissance du fonctionnement de la pile me parait
indispensable pour comprendre les differents types de passage
d'arguments.
Le passage des arguments est une fonctionalite abstraite definie par
le langage, la maniere de l'implementer sur ton architecture n'a
aucune importance. Et je ne vois pas l'utilite d'une pile pour
passer les arguments, on essaie plutot meme de l'eviter. (Je vois
l'utilite de la pile pour garder un contexte quand des appels
recursifs sont possibles, mais tous les langages n'autorisent pas le
recursivite).
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a
assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple
possible d'ordinateur. Son utilite pour apprendre a bien programmer
me semble douteuse. Elle peut avoir l'effet nocif de laisser penser
que la maniere evidente d'implementer quelquechose dessus est la
seule possible.
Et il est pour moi evident que mieux on connait le fonctionnement
interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un
exercice qui consiste a batir des abstractions sur d'autres
abstractions. Et quand on programme en C++, les abstractions de plus
bas niveaux utilisees sont celles fournies par le langage C++, pas
celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait. On ne
peut pas trouver plus concret.
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ET cela manque a bien des programmeurs.
"Jean-Marc Bourguet" a écrit dans le message news:"M.B." writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai
l'impression que tu va me donner une architecture typique des micro
des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann. Rien de
fondamentalement neuf depuis.
La connaissance du fonctionnement de la pile me parait
indispensable pour comprendre les differents types de passage
d'arguments.
Le passage des arguments est une fonctionalite abstraite definie par
le langage, la maniere de l'implementer sur ton architecture n'a
aucune importance. Et je ne vois pas l'utilite d'une pile pour
passer les arguments, on essaie plutot meme de l'eviter. (Je vois
l'utilite de la pile pour garder un contexte quand des appels
recursifs sont possibles, mais tous les langages n'autorisent pas le
recursivite).
Les arguments des fonctions passent TOUJOURS par la pile. Je suis
surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a
assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple
possible d'ordinateur. Son utilite pour apprendre a bien programmer
me semble douteuse. Elle peut avoir l'effet nocif de laisser penser
que la maniere evidente d'implementer quelquechose dessus est la
seule possible.Et il est pour moi evident que mieux on connait le fonctionnement
interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un
exercice qui consiste a batir des abstractions sur d'autres
abstractions. Et quand on programme en C++, les abstractions de plus
bas niveaux utilisees sont celles fournies par le langage C++, pas
celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait. On ne
peut pas trouver plus concret.A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ET cela manque a bien des programmeurs.
Dans tous les cas, le processeur empile les arguments, fait au saut a
la fonction appelée qui depile, execute, depile l'adresse de retour et
resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou
les bases de l'Assembleur.
Dans tous les cas, le processeur empile les arguments, fait au saut a
la fonction appelée qui depile, execute, depile l'adresse de retour et
resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou
les bases de l'Assembleur.
Dans tous les cas, le processeur empile les arguments, fait au saut a
la fonction appelée qui depile, execute, depile l'adresse de retour et
resaute a l'appelant.
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou
les bases de l'Assembleur.
"Jonathan Mcdougall" a écrit dans le
message news: fkFeb.104903$Que ce soit la pile ou un registre specialisé dans un
processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces
mecanismes, ca aide a comprendre certains effets pervers de
programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire
un peu plus l'attention des gens. Surtout quand c'est faux.
Non c'est pas faux. Une pile ou une serie de registres speciaux, c'est
du pareil au meme.
"Jonathan Mcdougall" <jonathanmcdougall@DELyahoo.ca> a écrit dans le
message news: fkFeb.104903$Wk2.1772201@weber.videotron.net...
Que ce soit la pile ou un registre specialisé dans un
processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces
mecanismes, ca aide a comprendre certains effets pervers de
programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire
un peu plus l'attention des gens. Surtout quand c'est faux.
Non c'est pas faux. Une pile ou une serie de registres speciaux, c'est
du pareil au meme.
"Jonathan Mcdougall" a écrit dans le
message news: fkFeb.104903$Que ce soit la pile ou un registre specialisé dans un
processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces
mecanismes, ca aide a comprendre certains effets pervers de
programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire
un peu plus l'attention des gens. Surtout quand c'est faux.
Non c'est pas faux. Une pile ou une serie de registres speciaux, c'est
du pareil au meme.
Dans news:blf0bf$8ot$,Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Il me semble que décaler au lieu de multiplier c'est aussi une
mauvaise connaissance de ce que font les compilateurs, une mauvaise
connaissance des règles de l'optimisation et une mauvaise connaissance
du processus de développement des logiciels (la maintenance).
Dans news:blf0bf$8ot$1@news-reader1.wanadoo.fr,
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Il me semble que décaler au lieu de multiplier c'est aussi une
mauvaise connaissance de ce que font les compilateurs, une mauvaise
connaissance des règles de l'optimisation et une mauvaise connaissance
du processus de développement des logiciels (la maintenance).
Dans news:blf0bf$8ot$,Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme. ET cela manque a bien des programmeurs.
Il me semble que décaler au lieu de multiplier c'est aussi une
mauvaise connaissance de ce que font les compilateurs, une mauvaise
connaissance des règles de l'optimisation et une mauvaise connaissance
du processus de développement des logiciels (la maintenance).
Non c'est pas faux. Une pile ou une serie de registres speciaux,
c'est du pareil au meme.
Non c'est pas faux. Une pile ou une serie de registres speciaux,
c'est du pareil au meme.
Non c'est pas faux. Une pile ou une serie de registres speciaux,
c'est du pareil au meme.
Les arguments des fonctions passent TOUJOURS par la pile.
ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme.
ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs.
Je suis d'accord qu'il est bien de savoir, par exemple, comment une
machine représente les entiers en binaire, mais pour bien de domaines
d'application, ce savoir ne me semble pas indispensable. Il s'agit de
savoir se placer sur le niveau d'abstraction approprié, qui n'est pas
le même si on écrit un driver pour un composant réseau (gestion des
registres, de la DMA, des interruptions ...) que dans le cas d'une
application qui traite des ordres d'achat / vente à la bourse...
Les arguments des fonctions passent TOUJOURS par la pile.
ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme.
ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs.
Je suis d'accord qu'il est bien de savoir, par exemple, comment une
machine représente les entiers en binaire, mais pour bien de domaines
d'application, ce savoir ne me semble pas indispensable. Il s'agit de
savoir se placer sur le niveau d'abstraction approprié, qui n'est pas
le même si on écrit un driver pour un composant réseau (gestion des
registres, de la DMA, des interruptions ...) que dans le cas d'une
application qui traite des ordres d'achat / vente à la bourse...
Les arguments des fonctions passent TOUJOURS par la pile.
ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand
on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on
programme.
ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs.
Je suis d'accord qu'il est bien de savoir, par exemple, comment une
machine représente les entiers en binaire, mais pour bien de domaines
d'application, ce savoir ne me semble pas indispensable. Il s'agit de
savoir se placer sur le niveau d'abstraction approprié, qui n'est pas
le même si on écrit un driver pour un composant réseau (gestion des
registres, de la DMA, des interruptions ...) que dans le cas d'une
application qui traite des ordres d'achat / vente à la bourse...
