Discussion :

[pierre.jourlin]

Bonjour,

Je suis enseignant-chercheur en informatique à l'université d'Avignon et je suis en train de développer un cours interactif qui porte pour l'instant sur les concepts fondamentaux du langage machine/Assembleur mais qui devrait dans un futur relativement proche aborder la structure des ordinateurs, la programmation structurée, la modélisation objet et la compilation.

Le cours est encore dans une version assez rudimentaire, mais j'ai besoin d'avoir quelques retours afin de pouvoir l'améliorer avant de le livrer à mes étudiants. Il est sous licence GNU FDL et il est accessible à cette adresse : http://www.cilma.univ-avignon.fr
N'hésitez pas à me faire part de vos commentaires.

Très cordialement,

Pierre Jourlin.

[mtopoloff]

J'aime pas trop que vous parliez de 'particules'....

Le programme est trop exigeant quand au navigateur, pourquoi ne pas utiliser du PHP / HTML standard plutot que du XML

Je n'ai pas de plugin SVG, pkoi est-il necessaire de l'avoir ?

Le cours pour apprendre l'assembleur semble plutôt complet, il manques peut etre des liens vers des sites de compilateurs reels (NASM, MASM, TASM)...

[pierre.jourlin]

merci pour votre message.

- XML est un format qui me permet de coder simplement les relations entre les différents concepts du cours. Cela me permettra de réaliser un grand nombre d'améliorations concernant l'nteraction.

- SVG c'est l'équivalent de Flash. C'est grâce à ce langage que sont réalisées les animations et les graphiques du simulateur de processeur que j'utilise dans les exemples du cours. A la différence de Flash, SVG est une norme du W3C. Il y a de bonnes chances pour que dans un futur proche, les navigateurs soient capables d'interpréter le SVG sans nécessiter de plugin.

- Il y aura peut être plus de 100 étudiants qui vont accèder à ce cours en même temps. C'est pourquoi j'essaie de limiter au maximum les accès au serveur en utilisant un minimum de PHP et un maximum de ECMAScript. Bien entendu, si votre machine n'est pas assez puissante, ça rame. Mais dans mon contexte d'utilisation, ça devrait le faire.

- Oui, vous avez raison, il faudra que j'ajoute des liens vers des assembleurs pour processeurs réels. Pour ma part, je suis plutôt partisan des outils GNU (gcc, gas, gdb).

- Qu'est ce qu'il ne vous plaît pas dans le terme "particule" ?

[Pouic]

Bonsoir,

votre site m'est aussi apparu comme très complet: un grand pour GIML !

Par contre, petit bémol: pourquoi avoir la FreeGnuLicense "en dur" a la fin de la page ? un petit lien en tête de la page ne serait-il pas plus approprié ? (je ne vois pas le rapport direct avec le cours....de plus, elle n apparait pas dans le sommaire)

[pierre.jourlin]

merci.

Concernant la FDL, je suis un peu d'accord avec vous, mais...
- Je pense que ce type de licence est d'intérêt public et qu'il faut la promouvoir.
- Auriez-vous remarqué la licence si elle n'était qu'un simple lien ?
- Dans tous les cas, elle doit apparaître dans le sommaire, merci pour la remarque.

Pierre Jourlin.

[mtopoloff]

Okok

A quand les spec pour les MMX, SSE et les procs RISK ?

[Blustuff]

Bonjour,

Je ne sais pas trop réelement à qui s'adresse ce cours, puis même si je le savais, la pédagogie c'est pas mon truc ^^ Enfin, je peux quand même essayer poser des question ou faire des remarques, on ne sait jamais ^^


Tout d'abord, j'avais cru au début que GIML était un processeur virtuel, très général, suffisement général pour que les particularité qu'on lui trouve s'appliquent à tous les processeurs, ou du moins à une grande majorité. Ce qui m'a alors frappé, c'est l'adressage. Je n'ai pas une culture très étendue, mais j'ai déjà travaillé sur un processeur qui n'avait pas de registres segments. On sort donc plus ou moins des concepts généraux. Mais alors, que je croyais que l'introduction de l'adressage segment:offset pourrait expliquer le fonctionement d'une catégorie de processeur, il se trouve que l'offset utilisé est codé sur 16 bits, et que l'équivalent du segment ne concerne que les 24 premiers bits de l'adresse 32 bits, si j'ai bien compris. Il n'y a donc aucun cas où par deux adressages différents on retombe sur la meêm adresse physique. Je trouve cela plutôt intégrant, même si vous aviez certainement une raison de procéder ainsi, j'ai du mal à comprendre pourquoi. Si quelqu'un devait apprendre à utiliser l'adressage en mode réel du x86, et même les autres, je penserais que s'il n'avait pas compris qu'il existait plusieures manière d'accèder à la même adresse physique, il n'avait pratiquement rien compris à l'adressage.


Ensuite, une question que je me pose depuis très longtemps et qui revient à cette occasion, c'est est-ce qu'il est nécessaire de parler du binaire pour parler de programmation assembleur. On retrouve souvent une phrase que je n'ai pas relevée ici, qui dit "Les ordinaires calculent en binaire". D'un point de vue électronique, ce n'est pas tout à fait faux bien que réducteur. Mais à mon sens c'était la mauvaise manière de voir les choses, puisque j'aurais plutôt pensé comme cela : "Le processeur fait des additions/soustraction/multiplications/etc. en base 2^8, 2^16 ou 2^32". Cette manière de voir les choses permet d'éviter il me semble de faire quelques amalguames et les confusion. Pour élargir le problème, il s'agit de ne pas confondre ce que représente les données stockées, et comment sont elles codées. Ce sont des problèmes de maturité essentiellement, qui s'ils n'était pas résolus empêcheraient d'assimiler la quasitotalité des optimisations matérielles, qui utilisent des opérations sans utiliser le sens qu'elles ont à la base. Ainsi sur un x86, on peut utiliser SBB sans pour autant vouloir faire une soustractions sur un grand entier.

J'aurais donc tendance à soutenir qu'introduire la manière dont sont codés les nombres en binaires pour la machine n'est peut être pas la première chose à faire. Vous dites d'ailleurs :

Par contre, les valeurs numériques qui sont contenues une case mémoire peuvent avoir une quantité illimitées d'interprétations différentes : nombres entiers naturels, nombres entiers relatifs, nombres rationnels, nombres réels, instructions, types, adresses, lettres, mots, phrases, couleurs, coordonnées dans l'espace, signaux sonores, etc.

Sans donner d'indice sur comment coder l'information, ce qui me conforte dans l'idée qu'il est trop tôt pour en parler ^^. Mais le codage de l'information n'est certainement pas la seule raison qui pousse à parler du binaire. Je ne saurais faire une liste exhaustive, mais ce qui me vient à l'esprit, ce sont les opérations binaires et (avec une certaine retenue) l'adressage. Les opérations binaires GIML ne semble pas encore en être dotées. Pour l'adressage, je veux parler des bits de poids faible, etc. Et c'est le seul point qui nécessiterait pour la compréhension de GIML qu'on parle de binaire avant. Mais la encore, je ne pense pas que ce soit impératif. On écrit en héxadécimal, parce que ca permet de regrouper quatre chiffres binaire en un seul hexadécimal, et que ca rend l'écriture bien moins laborieuse. Si on veut être relativement proche de la réalité évidement, autant garder la représentation héxadécimale. Mais on pourrait d'une manière théorique très bien écrire les données et les adresses en décimal, et dire qu'une "case mémoire" contient un chiffre de 0 à 9.

Voilà, donc remarque assez inutile ^^ pour peu que vous comptiez sur ce cours comme une introduction au binaire auquel cas, ma remarque est encore plus inutile qu'inutile : )


Enfin, plus un détail qu'autre chose. Je ne suis pas très réveillé et je confonds ma droite et ma gauche, mais il me semble tout de même voir une erreur :

Par convention, on dira que les chiffres les plus à droite sont de poids fort et les chiffres les plus à gauche sont de poids faible. En parlant d'une partie d'un nombre, on parlera de partie haute pour la partie la plus à droite et de partie basse pour la partie la plus à gauche. Par exemple, pour un nombre de valeur F9E8D7C6, nous appellerons partie haute de 8 bits la valeur F9, partie haute de 16 bits la valeur F9E8, partie haute de 24 bits, la valeur F9E8D7, partie basse de 8 bits la valeur C6, partie basse de 16 bits la valeur D7C6 et partie basse de 24 bits la valeur E8D7C6.

F9 est plutôt à fauche de F9E8D7C6, appelée donc partie haute, alors que vous définissez partie haute comme étant les chiffres les plus à droite. Dernier détail, les conventions ne sont souvent pas choisie au hasard, vous pourriez peut être expliquer pourquoi : )


[edit]Je trouve votre idée excellente, et réelement très efficace pour comprendre le fonctionement des processeurs. Il m'est venu juste une idée en l'air comme ca : Vous pourriez donner plusieurs niveaux de difficultés à GIML. En pur exemple : au niveau 1, il n'y aurait pas de registre segment, pas de registre d'état, et les nombres stockés en décimal. Seule les opérations arithmétiques simples seraient disponibles. Au niveau suivant, vous rajouteriez le registre d'état et les sauts conditionels. etc. Ce peut être un moyen d'arriver à des spécialisations, comme la reproduction proche d'un processeur existant etc.[/edit]



Amicalement, Blustuff.

[pierre.jourlin]

Merci pour ces commentaires détaillés.

- de manière générale, le cours s'adresse à des étudiants en bac+2 d'informatique. Il sera accompagné d'un cours "en présentiel" avec le Pentium comme support, mais c'est vrai que je n'ai pas comme objectif de faire de mes étudiants des experts en programmation assembleur mais plutôt de leur apprendre des concepts qui pourront leur être utiles jusque dans la pratique de langages évolués. Ce cours à distance doit être vu comme une aide "offline" à l'acquisition des concepts fondamentaux... Du coup, je m'aperçoit qu'il manque effectivement un passage la-dessus dans l'introduction!

Sur le registre segment :
- Je crois que quelqu'un qui en a compris les principes peut facilement s'adapter à un processeur qui n'a pas de registre segment ou qui utilise d'autres modèles d'accès à la mémoire. D'autre part, ce dispositif me permets tout simplement d'écrire des programmes plus longs dans un espace mémoire très réduit par des contraintes ergonomiques. Enfin, je cherche toujours un compromis entre réalisme, simplicité et ergonomie. Mais je pense que vous avez raison, je dois pouvoir le rapprocher un peu plus des 80x86 sans le rendre beaucoup plus compliqué à comprendre ou à utiliser..

- Sur l'introduction du binaire dans le cours, votre remarque est très utile : je suis justement en train de réfléchir aux liens entre les concepts du cours. Ce qui est strictement prérequis à quoi, etc. Concernant le binaire, il est certain que l'on peut atteindre un grand nombre d'objectifs pédagogiques sans le mentionner. Mais je pense aussi que tôt ou tard, il sera utile d'en parler. Comme l'explication de la base binaire ne demande quasiment aucun prérequis, je continue de penser qu'elle trouve bien sa place au début... enfin... je pourrais facilement changer d'avis sur cette question. Faudra que j'y réfléchisse un peu plus.

- Bien vu pour faible-haut-droit et fort-bas-gauche. Je me suis effectivement mélangé les pinceaux.

- Concernant le cours à différents niveaux : Ce que je prévois effectivement c'est une série de tests qui devraient permettre à l'étudiant de cerner les concepts qu'il a correctement acquis et ceux qu'il doit revoir. Je prévois aussi un dispositif qui permettra de remettre en question mes définitions en fonction des résultats des étudiants aux tests. Enfin, je prévois de pouvoir simplifier le cours en gérant de façon automatique les dépendances entre les différents concepts. Ca fait déjà une semaine que je me bats avec le développement d'une méthode de visualisation automatique du graphe de concepts (PHP+SVG)... J'ai encore du pain sur la planche.

Merci encore pour votre aide.

[Alcatîz]

Bonjour !

Je ressens également le même trouble que Blustuff : vous appliquez partiellement à un processeur fictif un principe d'adressage réel, qui plus est particulièrement peu intuitif. La segmentation hante le monde du PC depuis des décennies !

J'aurais trouvé plus naturel d'appliquer à une machine fictive un principe d'adressage fictif, de même qu'un jeu d'instructions limité et fictif. Ensuite seulement, aborder de manière concrète une machine réelle, en présentant de manière aprofondie un panel de principes bien réels, dont celui de la segmentation et des autres modèles d'adressage actuels, ainsi que des jeux d'instructions bien réels.

J'espère ne pas m'être exprimé de manière trop embrouillée ?