Archéologie, X86 et enseignement de l'info

[Møgluglu]

Ouai c'est le foutoir, mais franchement, pas plus tard qu'hier j'essayais de trouver quand certaines features x86 avaient été introduites... Et je n'y suis pas parvenu, bien que je sois loin d'être un handicapé en Googlerie.

Tu peux toujours demander ici

Alors moi j'ai une question: quand c'est qu'a été introduit le bit 6 (DAZ) du MXCSR SSE exactement?

Dans le manual IA-32 volume 1, il est décrit comme faisant partie de SSE2 avec la remarque:

In earlier IA-32 processors and in some models of the Pentium 4 processor, this flag (bit 6) is reserved.

Dans le Intel C++ Compiler User and Reference Guides, les intrinsics associés (_MM_SET_DENORMALS_ZERO_MODE...) font partie de SSE3.
Dans les headers de gcc pareil.
Dans MSVC ils sont passés complètement à la trappe : y'a les instructions AES de Westmere mais pas ce bit-là.

Les "some models of the Pentium 4 processor", c'est tous les Willamette / certains Willamette / juste une obscure révision buggée?

Edit: google semble pencher pour : à partir de Northwood...

Edit2: en fait non ou alors c'est qu'il y a une conspiration de gens qui postent des logs de Sandra truqués pour faire croire que Willamette supporte DAZ...

Edit3: la transition serait quelque part entre les steppings B2 et C1 de Willamette...

[fefe]

SSE2 donc P4 a partir d'un stepping de Willamette, Northwood etait un shrink avec bug fixes pas de changements d'architecture. Quel stepping, je ne sais pas (possible que ce soit juste la premiere serie a 1.4 mais faut que je retrouve)

The Pentium 4 processor can handle masked, denormal exceptions in SSE code more efficiently, if the “Denormals-Are-Zeros” (DAZ) mode is enabled. The DAZ mode is introduced with Pentium 4 processor to enhance the performance of SSE code when denormal input values are encountered occasionally. When the DAZ mode is enabled, denormal source operands are treated as zeros with the same sign. This architectural behavior applies to both single-precision and double-precision operands. When the DAZ mode is active, the denormal flag in the MXCSR register will not be set, irrespective of whether exceptions are masked or unmasked. The DAZ mode is available in the Pentium 4 processor in a subsequent stepping. Turning the DAZ mode on will improve significantly the performance of SSE applications that operate on denormal operands.

http://download.intel.com/design/Pen...s/24943801.pdf

Pour les intrinsics et leur historique je peux pas aider .

[newbie06]

Lorsque j'avais fait mes recherches j'étais tombé sur sandpile.org.
Dans ce cas, ça donne : http://www.sandpile.org/ia32/fp_new.htm
Mais je trouve que ça manque de précision...

[fefe]

Bon http://developer.intel.com/Assets/PD...ote/241618.pdf dit que certains steppings ne supportent pas le DAZ explicitement et liste la procedure pour le check. Malheureusement ca n'a pas l'air d'etre identifiable directement a partir du CPUID.

Il ne reste guere qu'a chercher les bug fixes des premieres versions de Willamette pour trouver quel stepping ne supporte pas (a priori ca doit le supporter mais un bug fix/chicken bit a probablement force la desactivation par defaut).
Il est sorti en B2, C1, D0 et E0. B2 a ete limite aux versions 1.3-1.4-1.5 et apparament n'avait pas DAZ, pour l'instant je pencherais pour dire que D0 et E0 avaient DAZ et pas sur pour C1 mais probable .

Bonjour l'archeologie .

[Møgluglu]

Merci.

Il est sorti en B2, C1, D0 et E0. B2 a ete limite aux versions 1.3-1.4-1.5 et apparament n'avait pas DAZ, pour l'instant je pencherais pour dire que D0 et E0 avaient DAZ et pas sur pour C1 mais probable .

Google me trouve ces deux dumps de Sandra:
http://www.cdrom-guide.com/forums/ar.../t-279980.html

Model : Intel(R) Pentium(R) 4 CPU 1400MHz
...
Revision/Stepping : 0 / 7 (8)
Stepping Mask : B2
...
DAZ - Denormals Are Zero : No

Et

http://www.hardwareanalysis.com/content/topic/24292/

Model : Intel(R) Pentium(R) 4 CPU 1500MHz
...
Revision/Stepping : 0 / A (8)
Stepping Mask : C1
...
DAZ - Denormals Are Zero : Yes

Donc ça serait bien le stepping C1.
Je peux maintenant enfin dormir tranquille.

Sinon, il y a une corrélation entre les steppings et les packages?
Ici le B2 est en 423 et le C1 en 478, c'est toujours vrai?...

[fefe]

http://www.chiplist.com/Intel_Pentiu...ection--2021-/
http://www.chiplist.com/Intel_Pentiu...ection--2022-/

B2, C1, D0 sont sortis en 423

C1, D0, E0 en 478

Donc si c'est un B2 c'est forcement du 423 si c'est un E0 c'est forcement du 478, C1 et D0 pas moyen de decider...
Conclusion si c'est un 478 DAZ est supporte, si c'est un 423 il faut tester le support pour voir si c'est un B2...

Pfiou...

[Møgluglu]

Enfin vu le nombre de Willamette B2 encore en circulation, et que personne de sain d'esprit n'irait essayer mon soft sur un P4 1.3GHz avec RDRAM, j'ai pas trop de souci à me faire.

Mais au moins j'ai appris un nouveau mot. Chicken bit, ça véhicule bien le concept.

[Dandu]

Pire, avec de la SD-RAM

[Lissyx]

Enfin vu le nombre de Willamette B2 encore en circulation, et que personne de sain d'esprit n'irait essayer mon soft sur un P4 1.3GHz avec RDRAM, j'ai pas trop de souci à me faire.

En plein dans le topic là du coup :D

[Møgluglu]

La discussion sur les flags en X86 m'a fait repenser à une autre question d'archéologie...

Dans l'Intel Optimization Guide de l'époque du P4, il était recommandé de faire add eax, 1 plutôt que inc eax.
Raison invoquée, inc n'écrase pas le flag carry, ce qui crée une dépendance partielle en lecture sur les flags.
Ce que je crois que je viens de comprendre, c'est pas parce que la gestion des dépendances considère toujours les flags comme un seul registre, c'est parce que ça force l'exécution de inc dans l'ALU lente?

Question (à ne pas poser) : pourquoi ça a été défini comme ça au départ?

Une première hypothèse c'est que ça servait à faire des additions multi-précision (en binaire ou plus probablement en BCD), avec un code genre :

loop:
mov ax, [si+cx*2]
adc [di+cx*2], ax   # lit C, écrit C
dec cx              # écrit Z
jnz loop            # lit Z

Comme ça, on évite que le inc/dec sur le compteur écrase le flag carry qui sert pour l'itération suivante.

Hypothèse tentante, mais il faut remonter un peu plus loin...
... jusqu'au 4004 en fait, où on retrouve exactement le même comportement :
http://download.intel.com/museum/archives/pdf/msc4.pdf




Là on se dit "ah bah oui, le 4004 c'est justement fait pour faire des calculs en BCD dans des calculatrices avec des registres de 4 bits qui contiennent chacun un chiffre, c'était donc bien ça!"

Sauf que... non. Déjà le 4004 n'a pas de flag Zero ou autre pour les comparaisons, juste le carry.
Et pour faire des boucles for, on utilise l'instruction ISZ :


(admirez la technique à la machine à écrire pour placer des indices à différents niveaux et les pointes de flèches ajoutées à la main par dessus les tirets)

Où le registre d'index qui sert de compteur est sur 4 bits et l'adresse dans le code sur 8 bits, ce qui limite un peu le genre de boucles qu'on peut écrire et me rend heureux d'être pas né à cette époque.

Donc bon, le mystère reste entier. Je crains que la réponse soit trés simple et décevante en fait...

[fefe]

La discussion sur les flags en X86 m'a fait repenser à une autre question d'archéologie...

Dans l'Intel Optimization Guide de l'époque du P4, il était recommandé de faire add eax, 1 plutôt que inc eax.
Raison invoquée, inc n'écrase pas le flag carry, ce qui crée une dépendance partielle en lecture sur les flags.
Ce que je crois que je viens de comprendre, c'est pas parce que la gestion des dépendances considère toujours les flags comme un seul registre, c'est parce que ça force l'exécution de inc dans l'ALU lente?

Ca passe par l'alu rapide suivi d'une instruction de merge des flags qui elle passe par l'alu lente si je ne me trompe pas... Donc bonjour la cata cote perfs...

[Møgluglu]

Encore une, plus récente (promis après j'arrête).

La sagesse populaire dit que faut pas changer souvent le contenu du registre de contrôle FP, parce que sinon ça stalle le pipeline (parce que c'est bien connu personne ne se sert de ce truc à part pour faire des casts de float vers int en C donc aucun architecte n'irait l'optimiser).

Néanmoins il y a quelques optimisations sur les CPU Intel.

Pour ce qui est du registre de contrôle en x87, le Performance Optimization Guide d'Intel dit:

On the Pentium III processor, the FLDCW instruction is an expensive operation. On early generations of Pentium 4 processors, FLDCW is improved only for situations where an application alternates between two constant values of the x87 FPU control word (FCW), such as when performing conversions to integers. On Pentium M, Intel Core Solo, Intel Core Duo and Intel Core 2 Duo processors, FLDCW is improved over previous generations.
Specifically, the optimization for FLDCW in the first two generations of Pentium 4 processors allow programmers to alternate between two constant values efficiently.

On trouve aussi une allusion ici:
http://developer.intel.com/technolog...oved_cores.htm

Another bottleneck that was discovered was the handling of the floating point (FP) Control Word (CW). The FP CW is part of the x87 state and was usually viewed as "constant"; namely it is loaded once at the beginning and stays constant throughout the program. This is indeed the way the FP CW is used by most of the programs. However there are some FP applications that manipulate the "rounding control" which is located in this register: the default rounding mode is "rounding to nearest even" but before converting results to fixed point, some applications change the round control to "chop" (this is the rule with C programs for example). Such behavior was treated rather inefficiently by the Pentium M core: each manipulation of the FP CW was effectively stalling the pipeline until its completion. The Intel® Core™ Duo core introduced a new renaming mechanism for the FP CW so that four different versions of this register can coexist on the fly without stalling the machine.

Donc Willamette et Northwood supportent d'alterner entre 2 modes d'arrondi, Yonah en supporte 4, et pour Banias/Dothan les avis sont partagés...

Sauf que c'est pas du tout ce que j'obtiens dans mes tests. Quand j'alterne entre 2 modes d'arrondi en x87 j'ai:
- Prescott (32-bit): OK
- Merom/Woodcrest (64-bit): KO
- Penryn/Wolfdale (64-bit): KO

Et surtout, tout ça ne parle que de x87. Quid du MXCSR de SSE?
D'ailleurs les fonctions de la libc qui manipulent ce genre de chose (fesetround & co.) modifient toujours à la fois le FCW et le MXCSR, du coup, si l'un des deux bloque c'est foutu.

Est-ce que ça pourrait être ce qui se passe ici? Genre rien n'a été prévu pour le SSE, au au contraire la version x87 est dépréciée?...

Si quelqu'un a des infos ou des liens vers des parchemins de l'époque...

[fefe]

Le registre de controle est partiellement renomme afin d'eviter les cata quand tu alternes entre 2 modes. Je ne me souviens absolument pas de ce qui est renomme ou pas mais je dois pouvoir le retrouver quelque part.

[newbie06]

C'est terrible ce poids du passé : devoir supporter le x87. LRB va supporter ça aussi je suppose, mais j'espère que les perf vont être pourries pour mettre en avant le SSEn et les instructions vectorielles.

Il y a eu un truc un peu pareil sur ARM, mais à l'envers : Cortex-A8 supporte un jeu d'instructions SIMD et a aussi une FPU. Mais la FPU est non-pipelinée ; ben ouai les mecs n'ont qu'à utiliser le SIMD ; dommage le SIMD n'est pas IEEE-754 et ne supporte pas les double. Epic fail

[fefe]

Disons que meme si un processeur supporte le x87 de maniere exceptionnelle, tu peux difficilement pretendre faire plus qu'un mul et un add en parallele (du au fait que le x87 travaille avec une pile et que meme si tu renommes le tout il reste beaucoup de serialisation artificielle). Si tu compares ca a une unite 512 bits qui peut te debiter jusqu a 16FMA par cycle, cela devient assez evident lequel est le plus rapide.

Bien entendu une unite vectorielle 512bits en double precision ne debiterait que 8 fma par cycle si elle etait prevue pour le double precision, ou 4 si elle n'a pas ete trop mal concue (en gros si le double precision etait au programme) alors que en x87 tu pourrais sortir un mul et un add 80 bits par cycle... Au final tu gardes quand meme un facteur 4 en DP et 16 en SP, sauf si tu veux du 80 bits. Pas trop difficile de convaincre qu'utiliser AVX est mieux qu'x87 dans ses conditions (a moins d'etre accro a la precision, ce que malheureusement beaucoup sont, pour des raisons aussi bonnes que: "80 bits c'est forcement mieux que 64 ou 32, non?").

Evidement tu peux aussi te debrouiller pour que ton unite vectorielle soit tellement mauvaise en double precision que le x87 soit plus rapide .

Bref, presque tous ceux qui savent ce qu'ils font utiliseront des modes vectoriels avec les algorithmes qui vont bien, le reste continuera a utiliser x87, certains pour de bonnes raisons, mais au final essentiellement pour de mauvaises.

[Møgluglu]

Le registre de controle est partiellement renomme afin d'eviter les cata quand tu alternes entre 2 modes. Je ne me souviens absolument pas de ce qui est renomme ou pas mais je dois pouvoir le retrouver quelque part.

D'après la doc (Optimization Guide 3.8.3) ce sont les flags Precision, Rounding et Infinity qui sont renommés.
Mais ça c'est sous Netburst, et encore peut-être pas tous, et en x87.

Sur Mobile et Core c'est nettement moins clair, la doc dit juste que ça a été amélioré par rapport à la génération précédente. Merci Intel...

À propos du registre de contrôle SSE, il y a ce passage:

It is expected that SIMD applications are unlikely to alternate between FTZ and DAZ mode values. Consequently, the SIMD control word does not have the short latencies that the floating-point control register does. A read of the MXCSR register has a fairly long latency, and a write to the register is a serializing instruction.

Je commence à avoir le pressentiment terrible que:
- les architectes d'Intel pensent que les changements de mode d'arrondi ne servent qu'à implémenter les casts en C (dans les SPEC, certes...),
- en SSE, on a les instructions CVTTSD2SI et CVTTSS2SI pour faire ces cast sans toucher au mode d'arrondi,
- conséquence, en SSE le registre de contrôle ne sert à rien. Ah si, à activer les modes FTZ et DAZ, ceux qui font gagner 50% de perf sur du traitement d'image de scène très sombre . Mais ceux-là on ne les active qu'une fois au début du programme (en ne réfléchissant surtout pas à l'effet que ça va avoir sur les libs qu'on utilise).
- conclusion, pas la peine de renommer le MXCSR .

J'espère que j'ai tord.

Tout ce que je peux dire, c'est que sur un code qui ne fait quasiment que des fesetround j'ai un effondrement de perf catastrophique sur Core mais pas autant sous Netburst (mon vieux Prescott pourrit un Xeon Woodcrest d'un facteur 5).
Mais il faudrait que je vérifie l'environnement soft, et que je fasse des tests plus ciblés...

Pas trop difficile de convaincre qu'utiliser AVX est mieux qu'x87 dans ses conditions (a moins d'etre accro a la precision, ce que malheureusement beaucoup sont, pour des raisons aussi bonnes que: "80 bits c'est forcement mieux que 64 ou 32, non?").

No way, je n'échangerai jamais mon FMA contre un baril de 80-bits!
(mais si on me donne les deux je suis heureux :itaniumforever: )

[Møgluglu]

Il y a eu un truc un peu pareil sur ARM, mais à l'envers : Cortex-A8 supporte un jeu d'instructions SIMD et a aussi une FPU. Mais la FPU est non-pipelinée ; ben ouai les mecs n'ont qu'à utiliser le SIMD ; dommage le SIMD n'est pas IEEE-754 et ne supporte pas les double. Epic fail

Le plus choquant, c'est pas tant qu'il reste du legacy immonde dans le jeu d'instruction, c'est surtout qu'on continue encore aujourd'hui à ajouter n'importe quoi sans réfléchir au futur...

Je suis d'accord avec le coup de gueule d'Agner Fog linké par fefe dans le topic microarchi. Il faut nommer un comité de normalisation, et quand ils se seront mis d'accord dans 20 ans on aura créé l'Ada du jeu d'instruction.

[newbie06]

Ha mais je ne parlais pas de virer les vieilleries, juste de les rendre inefficaces pour obliger les gens à passer à mieux. Enfin ça peut marcher à condition que les vieux soft soient remplacés, et là on n'a pas toujours le choix. Ce choix existait pour LRB, mais apparemment il n'a pas été fait.

Quant à avoir du x86 normalisé, je suis 100% d'accord : ça ralentira Intel, ça me plait

[Neo_13]

Je suis d'accord avec le coup de gueule d'Agner Fog linké par fefe dans le topic microarchi. Il faut nommer un comité de normalisation, et quand ils se seront mis d'accord dans 20 ans on aura créé l'Ada du jeu d'instruction.

Ben moi, je ne suis pas tout à fait d'accord. D'abord parce que penser aujourd'hui à l'informatique de dans 20ans, c'est forcément oublier des trucs (et je bosse dans un milieu dans le quel l'évolution est plus lente, et où d'une génération sur l'autre l'autre (4ans maximum) les pièces actées et pensées pour le futur nous font systématiquement chier...) et ensuite parce que même si on le faisait, on merderait : on peut écrire comme un porc des conneries en ada. Donc en plus, ça n'empêche rien.

Normaliser, c'est surtout un soucis de psychorigide. D'autant que les spec exhaustives sont distribuées chaque fois et que si on fait en n-1, ça marche aussi (mais grace aux archi qu'on torture pour ça).

Normaliser, c'est ralentir le progrès. Non que je sois contre... faut juste être sûr que le jeu en vaut la chandelle...

[newbie06]

Ralala tu as perdu ton sens de l'ironie toi Si Møgluglu parlait de normalisation et d'Ada dans la même phrase ce n'était pas pour rien...

[Møgluglu]

C'était ironique, mais ça n'empêche pas que j'aime beaucoup Ada. Le problème, c'est que je dois être le seul.
Ada est l'exemple typique du langage propre et bien défini construit sur des bases solides, conçu par un comité d'experts dans leurs domaines respectifs pour pouvoir être utilisé par tout le monde. Résultat : un langage de niche utilisé par 3 gus de l'aéronautique et 2 de la NASA...

Si on regarde les normes qui ont réussi, le processus est :
1. une implémentation ou un standard propriétaire s'impose,
2. on en fait une norme à la va-vite,
3. 20 ans après, on se rend compte que la norme est toute pourrite et on essaie de rectifier le tir avec une révision (qui est un vague compromis entre conservateurs et révolutionnaires et ne satisfait vraiment personne).

Exemples : IEEE-754, C, C++, Unicode/ISO-10646, OpenGL...
(Pour C et C++, la révision est seulement 10 ans après, mais il a fallu attendre 10 ans de plus pour avoir des compilo presque conformes. Pour Unicode et OpenGL on l'attend toujours...)

Sauf que si un comité avait dit à Kahan "tes modes d'arrondis dynamiques et tes traps ça va foutre la merde, change ça", ou à K&R "la sémantique de votre opérateur virgule c'est nimp", ou au consortium Unicode "le principe de vouloir associer un Han à un point de code c'est foireux, bande d'ethnocentristes", et bah on en serait pas là, hélas...

Mais il me semble quand-même défendable que pour x86 on commence à passer à la phase 2.

[fefe]

C'était ironique, mais ça n'empêche pas que j'aime beaucoup Ada. Le problème, c'est que je dois être le seul.
Ada est l'exemple typique du langage propre et bien défini construit sur des bases solides, conçu par un comité d'experts dans leurs domaines respectifs pour pouvoir être utilisé par tout le monde. Résultat : un langage de niche utilisé par 3 gus de l'aéronautique et 2 de la NASA...

Si on regarde les normes qui ont réussi, le processus est :
1. une implémentation ou un standard propriétaire s'impose,
2. on en fait une norme à la va-vite,
3. 20 ans après, on se rend compte que la norme est toute pourrite et on essaie de rectifier le tir avec une révision (qui est un vague compromis entre conservateurs et révolutionnaires et ne satisfait vraiment personne).

Exemples : IEEE-754, C, C++, Unicode/ISO-10646, OpenGL...
(Pour C et C++, la révision est seulement 10 ans après, mais il a fallu attendre 10 ans de plus pour avoir des compilo presque conformes. Pour Unicode et OpenGL on l'attend toujours...)

Sauf que si un comité avait dit à Kahan "tes modes d'arrondis dynamiques et tes traps ça va foutre la merde, change ça", ou à K&R "la sémantique de votre opérateur virgule c'est nimp", ou au consortium Unicode "le principe de vouloir associer un Han à un point de code c'est foireux, bande d'ethnocentristes", et bah on en serait pas là, hélas...

Mais il me semble quand-même défendable que pour x86 on commence à passer à la phase 2.

Toi t'as jamais du enseigner ADA (ou pas faire assez de TP ADA, la theorie c'est bien mais la pratique...) !!! Apres 3 ans de cours d'ADA ma conclusion etait que c'etait un langage propre, mais completement inutilisable et que je preferais donner des cours d'assembleur exotique a de l'ADA . Tu passes tellement de temps a essayer de compiler ton programme que ca ne vaut le coup que si tu developpes une application critique. Sinon autant avoir quelques bugs a la con mais mettre 3x moins de temps a developper .

[Møgluglu]

Je sais pas quelle mauvaise expérience tu as eu avec Ada, mais c'est pas du tout la mienne. Bon, j'ai juste codé quelques trucs simple en Ada il y a quelques années et enseigné un semestre en première année plus récemment...

Mais j'ai trouvé que les premières années (info/math/physique/élec/bio...) se débrouillaient bien mieux en Ada et se prenaient nettement moins la tête avec des détails de syntaxe à la con que les 2e année en C (info/phy/élec) (ou même avec les options du compilo et les include ).
Pour les erreurs de compil je trouve les messages d'erreur de gnat très clairs (pourvu qu'on ait vu en cours quelques mots du vocabulaire de la norme).
Et quand on me pose une question la réponse est beaucoup moins souvent "Parce qu'un mec a décidé comme ça dans les années 60, il devait être bourré ce jour-là, mais on peut plus changer maintenant."

Et puis surtout une fois qu'ils ont subi Ada en 1re année j'arrive à leur faire bouffer du VHDL en 3e sans qu'ils râlent trop.

Enfin c'est vrai que les concepts les plus avancés qu'on aborde sont les boucles sur les tableaux et les appels de procédure avec paramètres in/out... Pas de package à generics, pas de types access tarabiscotés, idem pour C l'arithmétique-de-pointeurs-et-l'allocation-dynamique-vous-verrez-plus-tard...

Mais pour que tout le monde soit content, on fait du lobbying pour mettre du Python à la place dans la prochaine maquette (au moins ça leur apprendra à indenter )

Sinon, ADA c'est un loueur de voiture ou une loi américaine sur l'accessibilité aux handicapés, le langage c'est Ada.

[fefe]

Je n'ai d'experience qu'avec le compilateur IBM sur RS6k, et c'etait infernal... Ma comparaison etait essentiellement entre enseigner Pascal et Ada (3 semestres d'Ada et 6 de Pascal), et pas avec C et autres. Pascal etait systematiquement plus pratique et tu passais plus de temps a enseigner l'algorithmique ou comment programmer que d'expliquer pourquoi le compilateur avait decide que tu ne pouvais pas affecter un int a un int . Bref entre Pascal et Ada comme langage imperatif pour faire decouvrir la programmation, le choix etait vite fait: Pascal gagnait systematiquement .

Cote interet futur dans la carriere du programmeur, les 2 etaient d'un interet assez limite je suis d'accord...

Bien entendu si tu dois apprendre Vhdl, etre passe par Ada aide pas mal . Mais si tu enseignes system-C et Verilog ca n'aide pas vraiment .

[newbie06]

WTF!?! Scheme et rien d'autre.

[fefe]

Ouais bon c'est vrai j'ai aussi eu droit a Scheme et CAML. Mais ce ne sont pas des langages imperatifs .

[newbie06]

Je m'insurge ! OCaml supporte l'impératif. Mais comme je ne l'ai jamais enseigné je ne sais pas trop ce que ça donne.

Dans mon souvenir, Pascal passait pas trop mal chez des débutants, tandis que C, même chez des gens qui avaient déjà fait du Pascal, ça ne passait pas. J'ai fait un tout petit peu de Scheme avec des débutants et ça passait pas mal (mais bon c'était des matheux aussi, donc le fonctionnel ça leur parlait).

[Møgluglu]

WTF!?! Scheme et rien d'autre.

Oui, c'est vrai qu'avec Pascal et Ada il reste encore un infime risque que ça leur serve à quelque chose plus tard.

Je m'insurge ! OCaml supporte l'impératif. Mais comme je ne l'ai jamais enseigné je ne sais pas trop ce que ça donne.

Pas si terrible (pas enseigné mais j'ai croisé pas mal de victimes)...
Caml est un merveilleux langage qui arrive à cumuler les défauts du fonctionnel avec ceux du C, avec un compilateur dont le répertoire des messages d'erreur va de "Syntax error at (1664, 51)." à "Cannot convert from [10 lignes] to [les 10 mêmes lignes avec une virgule qui change, ou même pas]".

Je trouve que c'est ni un bon langage fonctionnel ni encore moins un bon langage impératif... Pas pour les débutants sauf à les cadrer dans un style de programmation bien précis. Même problème que pour C++, sauf que C++ il sert dans la vie.

Dans mon souvenir, Pascal passait pas trop mal chez des débutants, tandis que C, même chez des gens qui avaient déjà fait du Pascal, ça ne passait pas. J'ai fait un tout petit peu de Scheme avec des débutants et ça passait pas mal (mais bon c'était des matheux aussi, donc le fonctionnel ça leur parlait).

Ouais mais j'aurai honte d'enseigner du Pascal en 2009, et va trouver un interpréteur/compilateur encore maintenu...
C devrait être interdit au moins de 20 ans, un langage hardcore comme ça, ça pourrait provoquer des profonds traumatismes.
L'inconvénient/avantage de Scheme c'est que ça décourage tout de suite les r0x0r du PHP qui forment la majorité des promos d'info...

[fefe]

Ca a un bon cote l'enseignement de langages exotiques inutilises, le jour ou tu te retrouves a programmer dans un langage a la con, tu as l'habitude des changements de syntaxe. Je ne connais la syntaxe de quasiment aucun (hormis quelques asm, mais ca ne compte pas), mais en 5 min je m'en sors en a peu pres n'importe quoi, et j'attribue ca au fait que j'ai appris la programmation avec des langages inutiles (et donc que quand j'ai eu besoin de programmer quelque chose d'utile, j'ai du m'adapter a de nouvelles syntaxes).
L'essentiel a mon avis est de comprendre les mechanismes de la programmation et l'algorithmique, pas l'apprentissage d'une syntaxe qui sera forcement inutile le jour ou l'etudiant sera face a un vrai probleme a resoudre dans un environement different de celui choisi par ses enseignants.

[newbie06]

Dans ma fac, ils avaient trouvé la solution pour Pascal : reverse engineering de Turbo Pascal 3, mise à la norme, et maintenance. Mais bon, c'était y'a 10 ans

Sinon je plussoie fefe. Il faut s'abstraire au maximum de la syntaxe et se concentrer sur les concepts fondamentaux de la programmation. C'est pour ça que je pense que les langages du type LISP/Scheme sont un bon choix, d'autant plus qu'ils sont aussi interprétés. (OK, j'avoue j'ai légèrement interprété les propos de fefe ).

En parlant de langage à la con, le pire que j'ai connu c'est Prolog (même si Prolog 3 et son moteur de contraintes était un peu plus amusant). Quant au plus amusant, j'hésite entre Modula2, CommonLISP et CAML. A l'arrivée, je ne fais que du C (et de l'assembleur, mais, désolé fefe, y'a pas de syntaxe là-dedans).