Vocabulaire et zepri de teuté

Pierre Maurette

17/12/2003 à 19:25

"Marc Boyer" a écrit

Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Ceci dit, même en assembleur, je défends explicitement l'idée que moins on
pense adresses dans la pile, mieux c'est.
En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces
adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai
parfois des doutes) l'implémentation des stack frames et donc de la
réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est
Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS.
Il y a un équivalent chez Motorola, et sans doute ailleurs.
Reste le problème de l'accès direct aux données de la pile (pas par
PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de
[ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon
macro-assembleur permet lui de ne jamais voir la variable autrement que par
son nom.

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.
Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Pierre

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit

Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Ceci dit, même en assembleur, je défends explicitement l'idée que moins on
pense adresses dans la pile, mieux c'est.
En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces
adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai
parfois des doutes) l'implémentation des stack frames et donc de la
réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est
Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS.
Il y a un équivalent chez Motorola, et sans doute ailleurs.
Reste le problème de l'accès direct aux données de la pile (pas par
PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de
[ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon
macro-assembleur permet lui de ne jamais voir la variable autrement que par
son nom.

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.
Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Pierre

Vous avez filtré cet utilisateur ! Consultez son message

"Marc Boyer" a écrit

Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Ceci dit, même en assembleur, je défends explicitement l'idée que moins on
pense adresses dans la pile, mieux c'est.
En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces
adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai
parfois des doutes) l'implémentation des stack frames et donc de la
réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est
Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS.
Il y a un équivalent chez Motorola, et sans doute ailleurs.
Reste le problème de l'accès direct aux données de la pile (pas par
PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de
[ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon
macro-assembleur permet lui de ne jamais voir la variable autrement que par
son nom.

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.
Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Pierre

Marc Boyer

18/12/2003 à 11:02

Pierre Maurette wrote:

"Marc Boyer" a écrit
Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Si on évoque l'assembleur, c'est autre chose.

[SNIP, détail des assembleurs]

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.

Oui, j'ai fait ça hiers soir, un joli shéma de lignes
d'éxecutions qui s'accumulent.

fact(x==1) |----------------------|
^ x==1? then return 1 |
| /
fact(x==2)|------------- | ---------|
x==1 ? else 2*fact(1) 1 |
/
2

Bon, au tableau c'était un parcours d'arbre avec profondeur 2,
mais là en ASCII-Art, j'ai eut la flemme.

Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Exactement, l'explication se fait très bien avec une pile d'assiette
Tant qu'on fait pas d'assembleur, on se moque de savoir si le processeur
fait monter ou descendre sa pile.

Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Pierre Maurette wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit

Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Si on évoque l'assembleur, c'est autre chose.

[SNIP, détail des assembleurs]

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.

Oui, j'ai fait ça hiers soir, un joli shéma de lignes
d'éxecutions qui s'accumulent.

fact(x==1) |----------------------|
^ x==1? then return 1 |
| /
fact(x==2)|------------- | ---------|
x==1 ? else 2*fact(1) 1 |
/
2

Bon, au tableau c'était un parcours d'arbre avec profondeur 2,
mais là en ASCII-Art, j'ai eut la flemme.

Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Exactement, l'explication se fait très bien avec une pile d'assiette
Tant qu'on fait pas d'assembleur, on se moque de savoir si le processeur
fait monter ou descendre sa pile.

Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Vous avez filtré cet utilisateur ! Consultez son message

Pierre Maurette wrote:

"Marc Boyer" a écrit
Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.

Si on évoque l'assembleur, c'est autre chose.

[SNIP, détail des assembleurs]

Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque

processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.

Oui, j'ai fait ça hiers soir, un joli shéma de lignes
d'éxecutions qui s'accumulent.

fact(x==1) |----------------------|
^ x==1? then return 1 |
| /
fact(x==2)|------------- | ---------|
x==1 ? else 2*fact(1) 1 |
/
2

Bon, au tableau c'était un parcours d'arbre avec profondeur 2,
mais là en ASCII-Art, j'ai eut la flemme.

Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).

Exactement, l'explication se fait très bien avec une pile d'assiette
Tant qu'on fait pas d'assembleur, on se moque de savoir si le processeur
fait monter ou descendre sa pile.

Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

adebaene

18/12/2003 à 16:40

"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<3fe050d7$0$7141$...

a écrit
[...]
La réincarnation, c'est quand tu as quitté une fonction, et que tu
appelles une autre fonction, qui n'initialise pas ses variables locales,
et que tu te rétrouves avec les variables de la fonction que tu as
quitté.

Comme technique de programmation, c'est à peu près aussi sûr que ne
l'est notre réincarnation à nous.
De la métempsychose au service de la programmation !

Sur la "technique de programmation", je me souviens d'un fil là-dessus il y
a quelque temps (ici ou chez les collègues du --). Le gars partait du
principe que les variables locales étaient bien "quelque part", et qu'en s'y
prenant suffisamment tôt, on devait pouvoir les "attraper". (intérêt ?).
Pour une implémentation l' "Aspect Oriented Programming" non ?

Arnaud

Michel Michaud

19/12/2003 à 04:20

Dans news:brru0c$jvt$, Marc

Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Ça ne change rien. Ça fonctionne tout autant et de la même
façon. En fait, c'est peut-être même plus facile à comprendre,
en autant évidemment qu'on ait d'abord compris le principe
des fonctions en assembleur (empilage des paramètres, espaces
pour variables locales, « stack frame », etc.). Là, clairement
on voit ce que sont vraiment les variables locales (et les
paramètres actuels). Évidemment je parle de l'assembleur d'un
processeur utilisant une pile, pour les autres, effectivement
c'est bien plus complexe.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

kanze

19/12/2003 à 09:01

"Michel Michaud" wrote in message
news:<S7uEb.19159$...

Dans news:brru0c$jvt$, Marc
Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Ça ne change rien. Ça fonctionne tout autant et de la même
façon. En fait, c'est peut-être même plus facile à comprendre,
en autant évidemment qu'on ait d'abord compris le principe
des fonctions en assembleur (empilage des paramètres, espaces
pour variables locales, « stack frame », etc.). Là, clairement
on voit ce que sont vraiment les variables locales (et les
paramètres actuels). Évidemment je parle de l'assembleur d'un
processeur utilisant une pile, pour les autres, effectivement
c'est bien plus complexe.

Ça doit dépendre des personnes. Il y en a qui ont plus de facilité
d'aller de l'abstrait au concret, et d'autres qui ont plus de facilité
d'aller du concret à l'abstrait.

Mais dans ce cas-ci, si l'élève apprend par l'assembleur, j'aurais peur
qu'il n'a pas saisi l'abstraction de la pile, ce qui est quand même
l'important dans l'affaire, et dans laquelle des conceptes tels que
« stack frame », etc., sont des détails d'une certaine implémentation,
qui est loin d'être universelle.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Marc Boyer

19/12/2003 à 09:31

Michel Michaud wrote:

Dans news:brru0c$jvt$, Marc
Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Ça ne change rien.

Ah...

Ça fonctionne tout autant et de la même façon.

Tout autant, j'en suis persuadé. De la même façon,
je doute (référence, variable statique, appel du
constructeur de copie -- puisque nous sommes du fclc++).

En fait, c'est peut-être même plus facile à comprendre,
en autant évidemment qu'on ait d'abord compris le principe
des fonctions en assembleur (empilage des paramètres, espaces
pour variables locales, « stack frame », etc.).

Oui, c'est vrai que je répette souvent que la récursivité
n'est qu'un cas particulier d'appel de sous-programme.

Là, clairement
on voit ce que sont vraiment les variables locales (et les
paramètres actuels). Évidemment je parle de l'assembleur d'un
processeur utilisant une pile, pour les autres, effectivement
c'est bien plus complexe.

Ce sont peut-être mes propres limites pédagogiques,
mais je préfere avoir le temps d'enseigner les fonctions
et la récursivité dans un langage un peu évolué (Pascal,
C, Ada, C++) *puis* l'assembleur.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Pierre Maurette

19/12/2003 à 10:38

"Michel Michaud" a écrit .

Dans news:brru0c$jvt$, Marc
Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Ça ne change rien. Ça fonctionne tout autant et de la même
façon. En fait, c'est peut-être même plus facile à comprendre,
en autant évidemment qu'on ait d'abord compris le principe
des fonctions en assembleur (empilage des paramètres, espaces
pour variables locales, « stack frame », etc.). Là, clairement
on voit ce que sont vraiment les variables locales (et les
paramètres actuels).

Pas nécessairement ;-) :

Factor PROC STDCALL USES ECX EDX N:DWORD
LOCAL VarRecurs:DWORD
.IF (N > 1)
mov edx, N
mov VarRecurs, edx
dec VarRecurs
INVOKE Factor, VarRecurs
mov ecx, N
mul ecx
.ELSE
mov eax, 1
.ENDIF
ret
Factor ENDP

Pourtant, c'est du MASM, pas un truc genre HLA.
Et je pense que le moindre utilitaire n'est au moins pas maintenable sans
les facilités d'un macro-assembleur.

Moins HS, puisque que les formateurs sont nombreux sur ce groupe :
Il me semble qu'il y a au moins deux types d'élèves face à un problème de
compréhension. Ceux du premier type ne pourront pas oublier qu'il y a une
machine hébergeant le programme, et auront besoin de savoir au moins en gros
comment ça peut marcher. Les autres se contenteront de ce que dit la norme.
Je fais de toute évidence partie de la première catégorie, mais j'admets
volontiers que ceux de la seconde seront sans doute plus productifs, dans
les situations de programmation les plus courantes.
J'ai connu un prof de C++ qui divisait les données en deux catégories,
celles créées sur le tas et celles créées sur la pile. Il enseignait à des
stagiares en automatisme et informatique industrielle, mais le C et le C++.
De plus, les automates utilisent des langages (terme parfois abusif) à haut
niveau d'abstraction. Et que dire de certains logiciels de supervision ....
Pierre

"Michel Michaud" <mm@gdzid.com> a écrit .

Dans news:brru0c$jvt$1@news.cict.fr, Marc

Après, si un élève découvre la récursivité avec l'assembleur,
c'est un autre niveau de difficulté (et j'aimerais pas être
le prof ce jour là).

Ça ne change rien. Ça fonctionne tout autant et de la même
façon. En fait, c'est peut-être même plus facile à comprendre,
en autant évidemment qu'on ait d'abord compris le principe
des fonctions en assembleur (empilage des paramètres, espaces
pour variables locales, « stack frame », etc.). Là, clairement
on voit ce que sont vraiment les variables locales (et les
paramètres actuels).

Pas nécessairement ;-) :

Factor PROC STDCALL USES ECX EDX N:DWORD
LOCAL VarRecurs:DWORD
.IF (N > 1)
mov edx, N
mov VarRecurs, edx
dec VarRecurs
INVOKE Factor, VarRecurs
mov ecx, N
mul ecx
.ELSE
mov eax, 1
.ENDIF
ret
Factor ENDP

Pourtant, c'est du MASM, pas un truc genre HLA.
Et je pense que le moindre utilitaire n'est au moins pas maintenable sans
les facilités d'un macro-assembleur.

Moins HS, puisque que les formateurs sont nombreux sur ce groupe :
Il me semble qu'il y a au moins deux types d'élèves face à un problème de
compréhension. Ceux du premier type ne pourront pas oublier qu'il y a une
machine hébergeant le programme, et auront besoin de savoir au moins en gros
comment ça peut marcher. Les autres se contenteront de ce que dit la norme.
Je fais de toute évidence partie de la première catégorie, mais j'admets
volontiers que ceux de la seconde seront sans doute plus productifs, dans
les situations de programmation les plus courantes.
J'ai connu un prof de C++ qui divisait les données en deux catégories,
celles créées sur le tas et celles créées sur la pile. Il enseignait à des
stagiares en automatisme et informatique industrielle, mais le C et le C++.
De plus, les automates utilisent des langages (terme parfois abusif) à haut
niveau d'abstraction. Et que dire de certains logiciels de supervision ....
Pierre

Marc Boyer

19/12/2003 à 11:41

Pierre Maurette wrote:

"Michel Michaud" a écrit .
Dans news:brru0c$jvt$, Marc

Moins HS, puisque que les formateurs sont nombreux sur ce groupe :
Il me semble qu'il y a au moins deux types d'élèves face à un problème de
compréhension. Ceux du premier type ne pourront pas oublier qu'il y a une
machine hébergeant le programme, et auront besoin de savoir au moins en gros
comment ça peut marcher. Les autres se contenteront de ce que dit la norme.
Je fais de toute évidence partie de la première catégorie, mais j'admets
volontiers que ceux de la seconde seront sans doute plus productifs, dans
les situations de programmation les plus courantes.

Je me garderais bien de porter un tel jugement, et en enseignement,
je tente de présenter les deux points de vue.
Mais de là à entrer dans les détails de pile qui monte avec des
adresses décroissantes...

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Vocabulaire et zepri de teuté

8 réponses

Veuillez sélectionner un problème