Discussion :

[Little Strong Mind]

Bonjour, Bonsoir,


Je suis en DUT informatique et on a commencé à travailler en assembleur (avec GNU il me semble). Je trouve ça très intéressant et je vous sollicite pour que vous -assembleurs qui assemblez avec un Assembleur en assembleur- pussiez m'aider à me documenter ur le sujet.

Il est question de livre ou de cours sur internet qui englobe tout ce qui est nécessaire à l'apprentissage de l'assembleur, c'est-à-dire un livre (de préférence) ou un cours web qui ne requiert pas d’aller chercher "trop" d'informations essentielles en dehors de son contenu.

J'ai aussi toujours cette micro frustration relative au fait de ne pas savoir si je commence par le "bon" côté de la chose... alors si vous pouviez m'indiquer un assembleur plutôt qu'un autre ou même me dire si cela aura une conséquence quelconque sur mon apprentissage j'en serai ravi.

Merci !

[TiranusKBX]

le problème avec l'assembleur c'est qu'il diffère selon le constructeur et la famille de processeurs
du coup tu te retrouve avec des tas de 'langages' mêmes si ils on des points communs
perso quand j'ai fait de l'assembleur c'était sur le Motorola 6800
et j'ai appris en lisant ceci LIEN vus que le prof à été Trèèèèèèèèèès succins ^^
Désolé si l'anglais te rebute

[Little Strong Mind]

484 pages... espérons que c'est un cours assembleur complet ^^
Du coup on ne peut pas vraiment dire qu'un langage assembleur soit plus "dur" qu'un autre ou plus approprié pour un débutant ?

[TiranusKBX]

le c serait plus approprié pour un débutant mais j'ai commencé par ça en électronique alors je ne vais pas me plaindre

[Little Strong Mind]

Le C pourra me permettre d'aborder plus sereinement l'Assembleur ?
je suis vaguement au courant qu'en C la gestion de la mémoire est plus poussée que dans d'autre langage mais faisant du python et du C++ et en y réfléchissant je me disais que sa serai sans doute plus logique de commencer par comprendre sur quel mécanisme se fonde ces langages non ?

[Forthman]

à mon avis, apprendre le C n'aidera en rien.
Les langages d''assemblage ne sont pas compliqués (au pluriel car je généralise), par contre, il faut connaître le fonctionnement
du processeur et la méthode d'accès aux périphériques (mémoires comprises)

Apprendre les instructions d'un processeur n'est que la partie émergée de l'iceberg
De toutes façons, les seules instructions à disposition, sont :
- déplacement d'octets en mémoire
- opérations logiques
- opérations arithmétiques basiques

Et il faut se démerder avec ça

Pas de définition de "types" pour les tableaux, tout n'est que suite d'octets, et à la charge du programmeur de savoir quel type de donnée
il veut utiliser. Là encore, suivant le proc, l'ordre des octets peut être de type little-endian ou big-endian

Puisque ça m'étonnerait que ton intérêt pour l'assembleur ne soit plus que passager, je te conseille d'utiliser le même
assembleur que celui de tes cours.

[Obsidian]

Bonjour,

Je suis en DUT informatique et on a commencé à travailler en assembleur (avec GNU il me semble). Je trouve ça très intéressant et je vous sollicite pour que vous -assembleurs qui assemblez avec un Assembleur en assembleur- pussiez m'aider à me documenter sur le sujet.

Effectivement les tutoriels sont légions, mais citer un bon livre d'apprentissage aujourd'hui reste toujours un exercice délicat.

J'ai aussi toujours cette micro frustration relative au fait de ne pas savoir si je commence par le "bon" côté de la chose... alors si vous pouviez m'indiquer un assembleur plutôt qu'un autre ou même me dire si cela aura une conséquence quelconque sur mon apprentissage j'en serai ravi.

Merci !

C'est une très bonne chose. Si tu as le goût de voir les langages « dans l'ordre » tels qu'ils sont apparus ces 30 dernières années, ce sera beaucoup plus facile car tu comprendras à chaque fois pourquoi tels ou tels choix ont été faits à un moment donné. Par ailleurs, si tu es au clair avec l'assembleur et l'architecture des ordinateurs en général, alors le C sera une formalité pour toi. Comme c'est un langage toujours très répandu même 40 ans après son apparition, ce sera un atout important.

Personnellement, je suis fan du 6809 et des 68xx(x) en général (Motorola 8, 16 ou 32 bits). Il faut savoir que dans les années 1980 (âge d'or de l'assembleur à mon avis, avec prolongation jusqu'en 1995 toutefois), les puces les plus répandues sur les différentes machines étaient le Z80, le 6502 (cousin du 68xx) et le 6809 dans une moindre mesure mais très présent en France parce qu'il a équipé les Thomson (MO5, MO6, TO7, TO8…) lors du plan Informatique Pour Tous. C'est un excellent micro-processeur pour débuter parce qu'il est ni trop simple ni trop compliqué, et que les opérations ont été bien choisies. Les rôles de l'ALU et des différents modes d'adressages apparaissent bien. Si tu as l'occasion de récupérer un vieux 8 bits pour faire tes armes dessus — ou de télécharger un de leurs nombreux émulateurs —, fonce.

Aujourd'hui, c'est surtout les x86 qui vont t'intéresser mais, comme j'ai déjà eu l'occasion de l'affirmer ici, c'est un peu comme apprendre à piloter directement sur A380 : il est à la fois trop puissant pour être assimilé entièrement dans un temps raisonnable et trop « unifié » pour que l'on en saisisse tous les mécanismes. Il y a peu de débutants, par exemple, qui comprennent pourquoi il y a une grande différence entre « INC EAX » et « ADD EAX, 1 ».

Mon « document de chevet » de l'époque étaient les pages 31 et 32 de ce papier : http://bitsavers.informatik.uni-stut...heets/6809.pdf (la datasheet officielle du fabricant) souvent reprise telle quelle, par photocopie, dans tous les ouvrages consacrés au sujet. On y voit clairement les instructions déclinées verticalement et classées dans toutes leurs représentations possibles ainsi que, horizontalement, les modes d'adressages du CPU, avec pour chaque combinaison le code opération associé, le nombre de cycles consommés et le nombre total d'octets occupés par l'instruction, soit le code opération lui-même suivi de ses paramètres. Le tout est agrémenté d'une description brève et de la combinaison des flags modifiés. On est censé trouver l'équivalent pour tous les micro-processeurs mais il est assez rare d'obtenir une table aussi synthétique. Notamment parce que ça dépend à la fois de la taille de la liste et de la manière dont le CPU a été lui-même conçu. Le 6809 est quasi-orthogonal, ce qui est presque mieux qu'une architecture parfaitement orthogonale, à mon avis.

L'intérêt de cette table, même si elle est aujourd'hui désuète (je ne dis pas obsolète car elle restera toujours valide sur un 6809) est d'avoir la totalité du fonctionnement du micro-processeur sous les yeux et de pouvoir être apprise facilement dans son entier. Pas la peine de le faire aujourd'hui, cependant. Néanmoins, ce jeu d'instructions-là est représentatif de ce que tu vas trouver à peu près partout, avec plus ou moins de sophistication.

[pfeuh]

Hello,

Bon, ben puisque nous en somme au rétro-computing, voici le jeu d'instructions de mon processeur préféré.

http://www.6502.org/tutorials/6502opcodes.html

Je pense qu'il est très intéressant de voir plusieurs processeurs, comment y est gérée la pile, comment on y lit-écrit une mémoire ou une i/o... Aujourd'hui il faut assez vite passer à autre chose, comme le C ou le python par exemple. Mais le temps passé sur les microprocesseurs et leurs jeux d'instructions n'est pas perdu, il aide à forger une façon de voir le bas niveau, ce que l'on a pas vraiment sans être passé par là. Une bête interruption par exemple, à part les gens qui bossent dans l'embarqué (et encore...), très peu de monde sait comment ça fonctionne.

A+

Pfeuh

[bifur]

ça fait aujourd'hui 10 ans que je fais de l'assembleur x86 alors aujourd'hui je ne me souviens plus trop avec quel bouquin j'ai commencé, je me souvien avoir utilisé (et ça m'arrive de l'uttiliser encore) le programme helppc (qui tourne sous DOS) pour avoir une documentation. aujourdhui j'utilise plutot le "Intel Architecture Software Developer’s Manual"
sinon je pense qu'il ne faut pas se focaliser sur une architecture, par exemple j'ai un peu etudier le 8051 pour travailler avec des microcontrleur


ps une version en ligne de helppc existe ici: http://stanislavs.org/helppc/

[Little Strong Mind]

Ooh on dirai que j'ai réveiller les rétros programmeurs de developpez ^^
J'ai relu tout les posts et ce que j'en ai retiré (dite moi si je me trompe) c'est qu'il faut que je connaisse le fonctionnement d'un micro processeur et le choix de l'assembleur importe peu, vrai ?

[TiranusKBX]

le choix de l'assembleur c'est choisir le proc mais sinon il est vrais ça à peut d'importance dans la globalité
sauf que ce ne sont pas les mêmes termes utilisés

[Little Strong Mind]

Compris pour ce qui est du choix de l'assembleur, du coup comme on ne va pas s'éterniser sur ce post, j'ai fait mes petites recherches en cherchant des documents sur les mécanismes de fonctionnement d'un micro processeur et sur l'assembleur GNU (je vais commencer par celui ci car je vais travailler avec en cours).


Mécanisme de fonctionnement d'un micro-processeur:

http://www.irisa.fr/alf/downloads/mi...ESIR2_2013.pdf

http://calcul.math.cnrs.fr/Documents...ours/Archi.pdf

http://web.univ-pau.fr/~ecariou/cour...ours-7-cpu.pdf

Je pense que j'aurai largement à faire avec ces 3 là... ^^

Cours sur GNU:

http://asm.developpez.com/cours/gas/

https://ensiwiki.ensimag.fr/images/a/a3/Asm09.pdf

Voila, si vous pouviez donner vos avis sur ces différents articles, si vous en trouver un inapproprié ou incomplet dite le moi et au besoin corrigez moi.

Merci !

[Kannagi]

Pour ma part , même si lire est assez important , il ne faut pas négligeais la partie pratique qui est non négligeable et qui permet (en tout cas pour moi) de mieux comprendre ce que cela fait , parce que quelque fois je ne comprend pas trop certaine explication mais on faisant des tests je comprend un peu mieux ce que cela fait.

Sinon je rejoins certains , je trouve pas le X86 le plus adapté pour commencé pour ma part le x86 ne m'avait pas plus attiré que ça et faire du X86 sur PC n'a pas beaucoup intérêt sauf refaire un OS ou programmé pour DOS , et je trouve que ce n'est pas le plus simple comme assembleur.

Les processeurs les plus courant a l'époque sont la famille des motorola 68000 et des 6502 , personnellement j'adore les deux , et j'ai une préférence pour le 6502 peu instruction et facilement assimilable.
Pour ma part vu que c'est la prog console qui m’intéresse avec ces 2 processeurs (qui ont des points commun) , ont peu programmé pour une vaste gamme de console de jeux vidéo NES (6502) , Super NES (65c816 dérivé du 6502) , mega drive ( 68000) , Neo Geo ( 68000), PC engine (qui a un processeur dérivé du 6502).
Et pas mal de vieux PC de l'époque Atari ST ( 68000 ) , Amiga ( 68000 ) et certain vieux Apple (6502).

Il y a un émulateur de 6502 en ligne : http://www.6502asm.com/

Ensuite le hardware de la machine n'est jamais négligeable vu que en assembleur on communique directement avec , donc si ta volonté et d'apprendre l'assembleur dit toi que tu en as pour quelque temps apprentissage vu que ça demande un investissement assez important.

Pour le C pour ma part je le conseille de l'apprendre et de l'approfondir , certes il n'est pas obligatoire pour apprendre l'assembleur mais reste un langage 'bas niveau' tout en ayant certain avantage , après tout dépend de ce que tu veux programmé mais admettons que quelqu'un qui voudrait programmer un jeux en assembleur , je le conseillerai de le faire en C d'abord , juste pour assimilé les divers techniques et algo relative au jeux vidéo je pense que les faire directement en assembleur avec peu expérience (sur le jeux vidéo et l'assembleur) serait un cassage de dent.

[Forthman]

La transposition Langage évolué -> Assembleur n'est pas toujours une bonne chose.
Quand on programme, on utilise les outils à disposition... et en Assembleur on n'a pas beaucoup d'outils
Et il faut souvent faire preuve d'imagination.

Juste pour l'exemple, dans un de mes programme en cours (x86), j'utilise un compteur 32 bits pour un watch-dog.
Ce compteur ne doit pas dépasser la valeur 000F.FFFFh sinon erreur de Timeout
Mais dans ma procédure de test, pour éviter d'utiliser un registre 32 bits (faut jongler pas mal sur x86 car pas beaucoup de registres)
j'utilise un registre 8 bits, et ne lis que le 3eme octet qui lui ne doit pas dépasser 0Fh

[Obsidian]

Ooh on dirai que j'ai réveiller les rétros programmeurs de developpez ^^

Ce n'est pas un hasard : Les années 80 et la première moitié des 90 ont été l'âge d'or de l'assembleur. Avant, l'informatique n'était pas assez répandue auprès du grand public. Après, le langage s'est déprécié pour plusieurs raisons : un public plus large (et demandeur de simplicité) est apparue, et les machines se sont complexifiées et ont gagné en puissance, ce qui a rendu l'approche « tout assembleur » a la fois plus difficile et moins intéressante.

Par ailleurs, on a longtemps cru qu'un compilateur, aussi performant soit-il, ne pourrait jamais égaler le niveau d'optimisation d'un programme écrit à la main par un authentique programmeur assembleur et c'est longtemps resté vrai. Ça doit l'être encore de manière « universelle » mais dans la majorité des cas, c'est justement en essayant de trouver un contre exemple avec les compilateurs actuels que l'on se rend compte à quel point il est devenu difficile de les battre. Certaines de leurs approches un peu bizarres s'avèrent en fait être les plus efficaces. En outre, la meilleure approche peut considérablement varier d'une version d'un micro-processeur à l'autre (surtout depuis l'introduction des pipelines). S'il est facile de recompiler un même programme pour différentes cibles, re-concevoir le même programme depuis zéro pour chaque famille est devenu inenvisageable, surtout s'il s'agit de familles proches. Par contre, ça se faisait beaucoup du temps des 8 et 16 bits, non seulement parce que les micro-processeurs étaient différents mais parce que les ordinateurs eux-mêmes étaient des engins propres à chaque fabricant, et pas une nième déclinaison de l'IBM PC, comme ce que l'on trouve aujourd'hui.

C'est dommage, d'ailleurs, parce que faire des programmes très optimisés pour une plateforme particulière (tout le contraire d'un programme portable, donc) en utilisant les subtilités d'une puce particulière et en l'exploitant dans ses moindres recoins était un des grands plaisirs de la programmation en assembleur. Arriver à les rendre les plus concis possibles en était un autre.

Avec cela, il faut aussi savoir que les machines ont fonctionné en « mode réel » (dénomination propre au x86 mais valable en pratique partout) depuis le premier micro-processeur début 1970 jusqu'à, formellement, l'apparition du 286 et surtout du 386 qui s'est popularisé dans le grand public autour de 1992. Les modes protégés des autres solutions commerciales étaient plus confidentielles. Donc, jusque là, un programme assembleur avait directement accès à toute la machine sans restriction et ça marchait très bien comme ça. En revanche, on était tous habitués à ne pouvoir lancer qu'un seul logiciel à la fois sur nos machines, ce qui à l'époque ne posait problème à personne. Sur PC, même dotés de processeurs performants, MS-DOS a perduré longtemps, surtout dans le monde du jeu vidéo qui par nature fait un usage intensif des ressources d'une machine. Ce n'est donc réellement qu'à partir de Windows 95 que le grand public, encore une fois, a basculé réellement dans un système réellement multitâches, préemptif et écrit depuis zéro pour utiliser le mode protégé. Il faut néanmoins signaler qu'à cette date, le noyau Linux existait déjà depuis quatre ans et qu'en ce laps de temps, des éditeurs comme Red Hat avait réussi à se développer et à sortir Red Hat Linux 2.0, déjà.

Ceci pour dire qu'il devient également difficile de proposer des exercices en assembleur qui soient intéressants, et c'est pour cela qu'il peut être profitable d'essayer, en parallèle avec le PC comtemporain, une machine de l'époque à la fois plus simple et faite pour. Comme elles n'étaient généralement pas équipées de disques durs, écrire un programme qui fasse tout planter n'est généralement pas catastrophique (il suffit de réinitialiser sa machine, la plupart du système se trouvant en ROM). Aujourd'hui, rien qu'écrire à l'écran est devenu une sinécure. Il faut obtenir un pointeur vers l'adresse de la page vidéo en cours, ce qui va dépendre de ta carte vidéo et de son pilote et dans tous les cas, il faudra réclamer au système l'autorisation de le faire sous peine de finir en segfault. Tant et si bien que la majorité de la programmation moderne consiste à appeler des directives sous-jacentes selon un format adapté aux langages évolués ce qui rend la chose pénible et sans intérêt sous assembleur.

J'ai relu tout les posts et ce que j'en ai retiré (dite moi si je me trompe) c'est qu'il faut que je connaisse le fonctionnement d'un micro processeur et le choix de l'assembleur importe peu, vrai ?

Presque mais pas tout-à-fait : de la même façon que les avions, par exemple, nécessitent chacun une qualification qui leur est propre mais partagent tous néanmoins les mêmes règles physiques et volent tous de la même façon, chaque assembleur va être propre à une famille de micro-processeurs mais ils vont tous être rédigés selon le même format (trois colonnes : étiquette, mnémonique du code opération, opérandes, plus les commentaires éventuels) et être compilés de la même façon : en une suite de 1 à 16 octets (en gros) par ligne, correspondant au code opération de l'instruction suivie de ses paramètres éventuels.

C'est aussi pour cela qu'on t'encourage fortement à aller voir la table des instructions du 6809 et du 6502, parce qu'elle est représentative des instructions que tu vas trouver sur la majorité des micro-processeurs et te donne en elle-même une idée de la façon dont ils fonctionnent. Par exemple, beaucoup de débutants vont se demander « quel est l'équivalent de l'instruction PRINT en assembleur », ce qui n'a en fait pas de sens. En réalité, un micro-processeur est indépendant de la machine dans laquelle il tourne et ne fait que lire des données quelque part, appliquer un traitement arithmétique ou logique dessus, et les réécrire ailleurs. Ce procédé permet d'émuler toute l'informatique moderne telle que nous la connaissons aujourd'hui.

En ce sens, il est intéressant de savoir effectivement comment fonctionnent les micro-processeurs en général, mais connaître sur le bout des doigts les architectures superscalaires ou les algorithmes prédictifs de branchement ne t'aidera pas à programmer en assembleur, surtout que cela ne concerne qu'un nombre restreint de produits.

Je peux néanmoins tenter une petite génèse :

• Au niveau industriel, l'électronique a explosé aussi vite que l'informatique l'a fait juste après. Cependant, elle reste a priori l'étude d'un phénomène physique, décrit par les mathématiques traditionnelles, et surtout un phénomène analogique ;
• Si toute la haute fidélité a pu se développer sur cette base, fabriquer des calculateurs analogiques (qui existent) reste peu pratique et il est difficile de les rendre fiables ;
• Les calculateurs sont été étudiés très vite mais avant même d'y penser, il y a eu un besoin grandissant d'appareils décisionnels, notamment pour la réalisation de tous les automates, comme les machines à café ou les monnayeurs des cabines téléphoniques. Ceux-là mêmes qui étaient jusque là réalisés de façon purement mécaniques. En particulier, ils devaient être capables d'examiner une condition ;
• À ce sujet-là, sont très vites apparues les portes logiques, en électronique bien sûr mais également en pneumatique (par cellules individuelles). Il s'agit de reproduire les conditions ET « ∧ », OU « ∨ » et NON « ¬ » décrite par la branche de la logique des bonnes vieilles maths, mais appliqués à des cas très triviaux : « si la pièce de monnaie est présente et que le bouton est enfoncé, alors faire couler le café ». En pratique, chaque porte logique est implémentée par deux à trois transistors seulement. Ça a aussi fondé la bonne vieille technologie TTL et la famille 7400 associée ;
• L'utilisation de conditions vraies ou fausses, « oui » ou « non » implique un fonctionnement en tout-ou-rien auquel se prêtent facilement les transistors. In fine, cela introduit aussi de fait l'utilisation du binaire ;
• La logique combinatoire devient vite reine : il s'agit de combiner plusieurs portes logiques pour implémenter des formules logiques complexes et donc des conditions très subtiles ;
• Ça a été utilisé longtemps. Par exemple, faire les poubelles de l'agence France Télécom du coin était une activité assez rentable pour récupérer du matériel réformé et dégoter des composants électroniques à peu de frais. On y a trouvé un jour une platine de cabine téléphonique relativement récente (pré-1990) au format A3 entièrement couverte de circuits logiques de la série 4000. La plaque entière ne servait qu'à implémenter une seule formule. Je pensais qu'à cette époque, on utilisait déjà massivement les réseaux logiques programmables (au moins) pour y parvenir ;
• Cela soulève le problème fondamental : le moindre changement de politique interne ou commerciale implique à chaque fois la re-conception et le remplacement de tous les automates en service sur le territoire et dans le domaine privé.

On a donc rapidement songé à concevoir des produits « universels », avant même d'être programmables. Parallèlement, les machines à calculer, y compris personnelles, commençaient à connaître un grand essor. De là, on a commencé à sortir des circuits électroniques capables d'effectuer de menus calculs, en binaire :

• Additionner deux nombres d'un bit de large chacun est trivial : s'ils sont nuls, le résultat est nul : s'il l'un vaut un et que l'autre est nul, le résultat vaut 1. Si les deux sont à 1, le résultat vaut 2, soir « 10 » en binaire, on pose alors 0 (et on retient 1). La table de vérité d'un additionneur binaire est alors exactement celle d'une porte OU Exclusif ;
• La retenue n'apparaît que lorsque les deux bits à additionner valent 1. Sa table de vérité est alors exactement celle d'une porte ET ;
• En montant en parallèle une porte ET et une porte OU Exclusif partagent les mêmes entrées, on construit un demi-additionneur 1-bit ;
• Pour tenir compte d'une éventuelle retenue précédente, il suffit d'ajouter celle-ci au résultat précédemment obtenu qui ne peut dépasser 3, soit « 11 » en binaire, de toutes façons. Pour ce faire, il suffit d'utiliser un second demi-additionneur pour ajouter la retenue entrante au résultat du premier, et de confondre les deux retenues sortantes à l'aide d'un simple OU. À ce stade, on obtient un additionneur 1-bit entier : 1 bit pour l'opérande A, 1 bit pour l'opérande B, 1 bit pour la retenue d'entrée, et 1 dernier pour la retenue sortante ;
• Si on chaîne plusieurs additionneurs en cascade, en reliant à chaque fois la retenue sortante à la retenue entrante du suivant, on obtient un additionneur de largeur arbitraire nommé « ripple carry ». Si on en chaîne huit par exemple, on obtient un additionneur 8 bits : 8 bits pour A, 8 bits pour B, une retenue entrante (celle du début de la chaîne) généralement forcée à zéro (mise à la masse), et une retenue sortante (à la fin de la chaîne) ;
• Faire un soustracteur est à peine plus compliqué : il suffit de complémenter le second opérande et d'ajouter 1. Pour inverser l'état d'un bit, il suffit d'utiliser là encore… un OU exclusif : donc une série de XOR bufferisant chaque ligne de l'opérande B, avec en entrée, d'un côté la ligne initiale et de l'autre, une ligne commune qu'il suffirait de mettre à 1 ou à 0. Comme il faut en plus ajouter 1, il suffit là encore de relier cette même ligne de commande à la retenue d'entrée, d'habitude toujours à zéro ;
• À ce stade, on dispose à présent d'un additionneur-soustracteur. On lui fournit un opérande A, un opérande B et un code opération, celui-là même que l'on retrouvera en sortie de nos compilations assembleur. Ici ce code tient en un seul bit et s'applique directement sur la ligne de contrôle. La signification est alors : 0 = ADDition ; 1 = SUBstraction ;
• Il est facile d'utiliser les mêmes lignes d'entrée et de les envoyer vers d'autres sous-circuits en parallèle et d'utiliser encore des portes logiques pour choisir la sortie que l'on souhaite retenir. Cela nous permet par exemple d'appliquer uniquement les opérations logiques, ou d'envoyer les données vers des registres à décalages, nécessaires non seulement pour toutes sortes d'applications pratiques (par exemple les UART…) mais également de mettre en œuvre tous les algorithmes arithmétiques travaillant au niveau du chiffre (donc ici le bit) ;
• Ces aiguillages seront commandés par des lignes de contrôle qui viendront se joindre à la première, formant ainsi des codes opérations sur plusieurs bits.

Arrivé là, tu disposes d'une « unité arithmétique et logique » ou ALU en anglais. Elles se vendent parfois au détail dans les magasins d'électronique mais tu les trouveras principalement au cœur des micro-processeurs dont elles forment en fait l'un des principaux organes. Il s'agit donc d'une unité de calcul en binaire rudimentaire mais dont les opérations te permettront à elles seule de construire toutes celles qui sont plus compliquées, comme la multiplication. Ça représente quelques centaines de transistors, mais intégrés sur une puce, c'est tout-à-fait raisonnable.

Pour que ce soit exploitable, maintenant, il faut interfacer cette puce avec son environnement et surtout trouver un moyen de lui distribuer ses données d'entrées, de sauvegarder le résultat quelque part, et de recommencer avec de nouvelles données. Jusque là, ton ALU était purement combinatoire. On va lui introduire une composante temporelle et donc lui associer un séquenceur :

• En combinant deux portes NON-ET, des portes logiques encore et toujours, tu formes une bascule. Ce qui est très fort, c'est qu'une bascule est en soi une mémoire de 1 bit, formée à partir de composants incapables en eux-mêmes de retenir la moindre information ;
• En les câblant d'une manière similaire à notre additionneur-soustracteur, on peut mettre en place des latches (verrous) ; La sortie de ces verrous suit l'état de leur entrée tant que la ligne de contrôle est dans un certain état et fige le dernier état enregistré quand elle en change. Ceci nous permet d'utiliser une entrée commune pour lire pour lire les différents opérandes et les placer devant leurs lignes d'entrées respectives ;
• Il faut empiler les données et les codes opération à la suite pour qu'ils puissent être lus successivement. On peut le faire par exemple sur une carte perforée. Chaque « ligne » d'une grande bande verticale contiendrait par exemple huit trous, plus un pour faire passer les picots d'une roue dentée, ce qui permettrait de la faire avancer. Des capteurs optiques ou simplement électriques devant les trous suffisent à lire leur état, et une impulsion électrique pourrait suffire à faire avancer la roue d'un cran, donc à l'incrémenter ;
• Le séquenceur peut donc se résumer à une horloge envoyant des impulsions à intervalles fixes, servant à la fois à faire avancer la carte et à orienter l'entrée à tour de rôle vers les lignes de contrôle, les verrous de l'entrée A et les verrous de l'entrée B ;

À ce stade, tu peux considérer que tu disposes d'un micro-processeur.

Compris pour ce qui est du choix de l'assembleur, du coup comme on ne va pas s'éterniser sur ce post, j'ai fait mes petites recherches en cherchant des documents sur les mécanismes de fonctionnement d'un micro processeur et sur l'assembleur GNU (je vais commencer par celui ci car je vais travailler avec en cours).

[…]

Voila, si vous pouviez donner vos avis sur ces différents articles, si vous en trouver un inapproprié ou incomplet dite le moi et au besoin corrigez moi.

Les slides de ESIR2 sont les plus complets mais ceux de E. Cariou sont les plus proches de l'approche que j'aurais moi-même à ce sujet.
Bien qu'utilisateur de Linux convaincu, je ne suis pas spécialement fan de l'assembleur GNU (syntaxe AT&T) et on est peu nombreux à l'être. Je préfère la bonne vieille syntaxe Intel, conforme à ce que l'on trouve ailleurs également, beaucoup moins verbeuse (et avec les registres dans le bon sens).

[bifur]

obsidian, tu rajoute quelques shémas et tu auras le premier chapitre de ton bouquin sur l'assembleur (voir même sur LES assembleurs)

et puis je confire ce que tu dit personne n'aime la syntaxe AT&T, apart peut être les linuxiens mais je suppose que c'est pour ça qu'il n'en font jamais

[Rekin85]

Bonjour

Obsidian : CHAPEAU ! J'ai rarement vu une aussi grande qualité pédagogique pour "éclairer" un étudiant qui veut se lancer dans l'assembleur...

Pour ce qui concerne le 6809 de la famille des TO , je me souviens d'un ouvrage-bible qui, si je ne me trompe pas, (il y a quand même longtemps...) s'intitulait : "l'assembleur du 6809" par Bui Minh Duc. J'avais, grâce à lui, à l'époque écrit un traitement de texte pour TO (3 ans de boulot en amateur) qui n'a eu aucun avenir car le plan Informatique pour tous avait tourné court...

[Obsidian]

obsidian, tu rajoute quelques shémas et tu auras le premier chapitre de ton bouquin sur l'assembleur (voir même sur LES assembleurs)

Bonjour
Obsidian : CHAPEAU ! J'ai rarement vu une aussi grande qualité pédagogique pour "éclairer" un étudiant qui veut se lancer dans l'assembleur...

Merci beaucoup pour vos appréciations car j'ai eu peur de trop m'étendre, mais il me semblait depuis longtemps que c'est le genre d'introduction qu'il manque aujourd'hui à la discipline, parce qu'elle n'apparaît plus de façon évidente comme cela pouvait être le cas avec les anciennes machines…

Effectivement, ce serait mieux avec quelques schémas. Ça fait un moment que je songe à écrire un petit papier à publier ici mais ça demande beaucoup de temps et pas mal de vérifications pour ne pas dire trop d'âneries. Ce n'est pas grave si je fais de petits écarts avec l'histoire dans ce commentaire mais ça le serait plus dans un document officiel.

et puis je confire ce que tu dit personne n'aime la syntaxe AT&T, apart peut être les linuxiens mais je suppose que c'est pour ça qu'il n'en font jamais

Ce n'est pas tout-à-fait vrai. Enfin, initialement, plusieurs personnes considéraient l'assembleur sous Unix comme un « sacrilège » parce qu'UNIX et les logiciels libres étaient faits pour être le plus portable possible et parce que le C a été inventé par les mêmes personnes. C'est pour cela qu'il reste le langage de prédilection pour la programmation système. Cela dit, c'était surtout vrai quand l'assembleur était plus répandu et comme les personnes qui s'intéressent à l'assembleur sont généralement les mêmes, c'est quand même sous Linux qu'on finit par trouver le plus d'outils (libres).

Pour ce qui concerne le 6809 de la famille des TO , je me souviens d'un ouvrage-bible qui, si je ne me trompe pas, (il y a quand même longtemps...) s'intitulait : "l'assembleur du 6909" par Bui Minh Duc.

Ah, le beau bouquin rouge ! On me l'avait prêté à l'époque et je ne l'ai « pas encore » rendu à son propriétaire. :-)

J'avais, grâce à lui, à l'époque écrit un traitement de texte pour TO (3 ans de boulot en amateur) qui n'a eu aucun avenir car le plan Informatique pour tous avait tourné court...

À tout hasard, ce n'était pas « momot », ce traitement de texte ?

[Rekin85]

Bonjour Obsidian

Momot ! Non... Ce n'est pas moi. Le mien s'appelait PRETEXTE.

C'était à l'époque du Plan IPT de Laurent Fabius. Des TO7 et MO5 avec tables, moniteurs télés et magnétophones avaient été distribués en grand nombre dans les écoles primaires françaises avec RIEN à faire tourner dedans sinon un petit basic dit microsoft et une pauvre tortue logo. Quel gâchis ! (Je sais pour avoir été dans le système longtemps que certains de ces ordis sont encore dans les cartons au fond des placards à balais de certaines écoles publiques reculées... Hé oui ! )

Comme j'étais à l'époque formateur des instituteurs de terrain (!) je fus convié à participer à la formation de base des IUFM. J'ai donc commencé par du Print"Bonjour" avec ensuite pas mal de goto et gosub sur des claviers en touches de chewing gum. Mais, faute de logiciels assez rapides, dans les classes, il ne s'est pas passé grand chose avant l'arrivée des P.C.

Pour moi, ce fut la révélation de la programmation, et placé en face des besoins des instituteurs, je me suis rendu compte qu'il fallait vite leur bâtir des outils plus véloces et intelligents que les jeux idiots écrits en basic ou logo que l'on appelait entre collègues les logiciels flippers...

En traitement de texte est arrivé le fameux TGVTexte vite rebaptisé TGTTexte à cause du TGV déposé par la SNCF. C'était une catastrophe de langueur et d'usine à gaz d'utilisation. Un collègue très passionné me fit découvrir les apports de l'assembleur pour accélérer surtout le graphisme. Le livre rouge (quelle mine !) et en autodidacte, j'ai réussi avec pas mal de temps et patience à maîtriser l'assembleur du 6809 grâce à la cartouche du langage machine dédiée au TO. Essais et erreurs, faire de l'asm avec le compilateur sur bande de magnétoscope pour revenir en RAM ensuite : c'était ce qu'on appelait l'assembleur par les plantes !

En plus, avec 48 ko disponibles en RAM pour le programme et les data, la moindre petite économie de code était vitale : une belle école de rigueur... 3 ans de boulot-passion du soir (et de la nuit...) pour obtenir un beau petit traitement de texte tout asm avec lequel on pouvait taper du texte au kilomètre (pas plus d'une page A4), avec des menus déroulants (comme le Mac) et un module de mise en forme du texte en vue réduite. J'en étais très fier. Beaucoup de collègues de mon département l'on utilisé avec bonheur pour les petits journaux d'écoles car le CDDP local avait bien voulu en assurer la promotion et mes collègues formateurs en assuraient la présentation dans les stages de formation continuée...

Trop tard ! Les P.C. arrivaient avec leurs Word et excel sous DOS. La joie pour moi fut que quelques petites écoles de campagne m'envoyaient leur beaux petits journaux édités avec Prétexte. J'en ai gardé une disquette qui maintenant doit être illisible (?) et tout le source et la notice d'utilisation sur papier (j'avais déposé le source auprès de la SPL)...

[Obsidian]

C'était à l'époque du Plan IPT de Laurent Fabius. Des TO7 et MO5 avec tables, moniteurs télés et magnétophones avait été distribués en grand nombre dans les écoles primaires françaises avec RIEN à faire tourner dedans sinon un petit basic dit microsoft et une pauvre tortue logo. Quel gâchis ! (Je sais pour avoir été dans le système longtemps que certains de ces ordis sont encore dans les cartons au fond des placards à balais de certaines écoles publiques reculées... Hé oui ! )

En fait, j'ai énormément bossé sur mon Thomson également. Outre les « forums Thomson » organisés une fois par an en région parisienne entre 1991 et 2010, j'ai également pas mal bricolé ceux des écoles (à commencer par la mienne). Le TO7 est sorti quand j'étais en CP. Beaucoup plus tard, j'ai retapé le parc de la SEGPA d'un collège de Seine-Saint-Denis. J'ai également écrit quelques logiciels dessus, si bien que l'on m'a confié quelques demi-classes. C'était agréable.

Comme j'étais à l'époque formateur des instituteurs de terrain (!) je fus convié à participer à la formation de base des IUFM. J'ai donc commencé par du Print"Bonjour" avec ensuite pas mal de goto et gosub sur des claviers en touches de chewing gum. Mais, faute de logiciels assez rapides, dans les classes, il ne s'est pas passé grand chose avant l'arrivée des P.C.

Il y avait quand même le nanoréseau :-)

En traitement de texte est arrivé le fameux TGVTexte vite rebaptisé TGTTexte à cause du TGV déposé par la SNCF. C'était une catastrophe de langueur et d'usine à gaz d'utilisation.

Pour le coup, ce n'était pas une mauvaise chose de le renommer, alors… :-)

En plus, avec 48 ko disponibles en RAM pour le programme et les data, la moindre petite économie de code était vitale : une belle école de rigueur... 3 ans de boulot-passion du soir (et de la nuit...) pour obtenir un beau petit traitement de texte tout asm avec lequel on pouvait taper du texte au kilomètre (pas plus d'une page A4), avec des menus déroulants (comme le Mac) et un module de mise en forme du texte en vue réduite. J'en étais très fier. Beaucoup de collègue de mon département l'on utilisé avec bonheur pour les petit journaux d'écoles car le CDDP local avait bien voulu en assurer la promotion et mes collègues formateurs en assuraient la présentation dans les stages de formation continuée...

On a fini par désassembler le BASIC et le moniteur du TO8D et des machines de la même génération. J'y ai trouvé quelques pépites cachées comme « PEEK$(x,y) » mais surtout, on a pu constater qu'en 32 Ko (deux banques de 16) tenait un véritable petit système d'exploitation : tout l'éditeur du BASIC, mais également toutes les fonctions qu'ils proposait, rassemblés sous ce qui s'appelait Extramon et qui assurait tout le travail sérieux comme la gestion des périphériques, les fichiers de haut niveau calqués sur le modèle du DOS et les fonctions mathématiques. Découvrir notamment comment étaient déterminées les valeurs de EXP(x) et LOG(x) a été un vrai plaisir.