Discussion :

[chrtophe]

L'assembleur est peut-être encore utilisé pour programmer des robots, et encore, la plupart des micro-contrôleurs sont fournis avec des bibliothèques.

C'est par contre utile pour comprendre le fonctionnement de l'ordinateur.

C'est utilisé aussi par les crackeurs.

[Forthman]

Je viens de tester ce matin la communication sur port série avec DosBox(linux), et ça fonctionne aussi (après en avoir autorisé l'accès)
Je précise que c'est en accès direct au port I/O

[Luke spywoker]

Merci pour vos nombreuses interventions sur ma question concernant la dosbox.
Pour l'instant j'étudie les instructions (listé dans mon livre d'apprentissage), mais je reviendrai sur le matériel et là j'aurai besoin de la fameuse dosbox malgré que j'ai fait une succincte tentative avec...

Il me faudrait juste donc que je trouve un moyen d'afficher quelque chose sur la stdout sous DOS (pour debug en echo), je vais essayer de me débrouiller pour ce détail, qui n'est pas facile pour moi le Linux geek de la nouvelle génération, qui ne connaît vraiment pas grand chose de la programmation sous Windows et encore moins sous DOS.
Linker la libc pour un extern printf ou un appel système a write ne sera pas possible dans ce cas la.

Sinon encore 2 petites questions:

1) Est-ce difficile de passer de la syntaxe INTEL x86 a INTEL 64 bits ?

2) Est-ce-que la différence entre les syntaxes INTEL et AT&T (syntaxe de gnu assembler) est simplement d'ordre syntaxique ou est-ce un autre langage de programmation ? Connaissez vous les deux syntaxes par exemple ou est-ce un gros changement ?
J'ai remarquer succinctement que la source et la destination sont inversées.

Je prévois pour l'avenir...

Merci pour vos réponses éclairées.

PS: le plus dur a l'air d'être les instructions de contrôle du processeur.

[chrtophe]

Pour afficher du texte, tu as des fonctions DOS (int 0x21) ou même BIOS (int0x9)

Je me rappelles plus les sous-fonctions mais c'est facilement trouvable.

Les syntaxes intel x86 et 64 bits sont les mêmes. Les registres passent de 32 bits à 64 bits.
exemple eax : 32 bits, rax : 64 bits la partie 32 bits reste accessible via eax comme la partie 16 bits d'eax avec ax.

Pour utiliser les adresses 64 bits, il faut passer en long mode, tu as une procédure. Il y a un mode legacy pour la rétrocompatibilité. En 64 bits, il n'y plus de gestion de taches je crois (d’où incompatibilité des applis 16 bits, le CPU ne pouvant créer une entrée TSS 16 bits).

Oui, la différence entre la syntaxe Intel et AT&T n'est que d'ordre syntaxique. La différence n'est pas énorme. Le point le plus important est comme tu l'as dit l'inversion de la source et de la destination. Je n'utilise pas la syntaxe AT&T mais suis capable de la comprendre. Je crois que la AT&T est la plus universelle si tu prends tous les CPUs. Gnu assembler est un assembleur pour plusieurs type de CPU, d’où l'usage de la syntaxe AT&T.

GNU Assembler est capable d'utiliser la syntaxe Intel.

[Forthman]

pour la liste des interruptions en 16 bits (avec dosbox donc) tu peux aller voir ce site c'est une mine d'or :
http://www.gladir.com/LEXIQUE/INTR/INT00A07.HTM

[Luke spywoker]

Salut,
J'ai pas essayer de programmer le système avec la dosbox, je n'en ai pas eu le courage, sachant que c'est dépassé (aussi les notions abordées dans mon livre d'apprentissage a ce sujet) et inutile si l'on ne souhaite pas faire de programmation système mais uniquement de l'applicatif.
Pour cela si j'y vient un jours je pense le faire avec ma petite expérience du GNU C.
D'ailleurs j'ai publier un petit tutoriel a ce sujet après mes expérimentations
intitulé: Débuter en kernel-programmation avec un driver en mode caractères .

Pour répondre a ma propre question je vient de lire un livre sur la programmation assembleurs 64 bits (syntaxe Intel) sous Linux et c'est vraiment facile de passer du mode 32 bits au 64 bits.
Le livre est écrit en anglais par un ancien (dinosaure) de la NASA et est excellemment bien rédigé de manière pédagogique et mettant en avant la pratique, la plupart des instructions sont abordés malgré quelles ne soit pas bien décrite de manière listé dans un annexe ou un chapitre dédié.
Et coté de la langue anglaise ne m'a causé aucun soucis. Un bon livre pour débuter pas comme le livre sur le x86 écrit en français mais dont je dirai que ça m'a bien servis de base pour aborder le 64 bits.

Mais dont ont peu dire beaucoup de mal en tant que débutant:

1) Les codes exemples sont pratiquement tous a exécuter en mode réel, ce qui est rebutant pour un débutant.

Mais il a de bon cotés:

1) Un bonne approche par rapport au binding de l'assembleur au matériel.
2) Un listing des instructions classées par types puis alphabétiquement.

Brefs en environ 2 semaines j'ai lu 2 bouquins et je pense maîtriser maintenant les bases de la programmation assembleurs sous Linux.
A moi d'aller plus loin et peut-être un jours écrire un vrai soft en assembleur.

C'était le plan:
Apprendre la programmation assembleur x86 servant de tremplin pour le 64 bits...
J'adore quand un plan se passe sans accrocs.

En tant que Linux geek ce commentaire m'intéresse vraiment:

GNU Assembler est capable d'utiliser la syntaxe Intel.

Sa serai sympa de développez si vous le désirez bien. Une option de as ???

Merci pour votre aide tous le monde en espérant qu'on se révérât un de ces quad sur ce forum...

PS:
l'environnement de développement ebe (Easy Beginner's Environment) est un bon software il permet entre autre:
de débugger son code avec en cliquant simplement sur la ligne ou l'on souhaite placer un breakpoint, un bouton nexti et run.
Il dispose également d'une fenêtre de terminal qui renvoie la sortie du programme,
et d'une fenêtre permettant d'entré des commandes gdb.
Une fenêtre affichant les valeurs de chaque registre pendant une exécution pas-a-pas.
Et l'on peut activer|désactiver les fenêtres souhaitées et les positionnées oû l'on veut dans la GUI.
Etc..

La première version était écrite en python avec Tkinter et il existe une version écrit en C++ avec QT.

[Kannagi]

ben une recherche sur google et tu aurait trouvé pour la syntaxe intel.

Mais voici un exemple de code sur un code C que j'avais fait pour testé (il y a quelque variable):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
asm( ".intel_syntax noprefix;" );
    asm("mov eax,300\n");
    asm("mov eax,s\n");
    asm("add eax,sizeint\n");
    asm("add eax,sizeint\n");
 
    asm("mov tmp,eax\n");
 
    asm( ".att_syntax noprefix;" );

Mais faire de assembleur sur du C sous linux n'a aucun intérêt , vu que tu n'aura pas accès au matériel(si je me trompe pas sur linux seul le kernel a le droit donc cela veut dire rebooter a chaque fois en le modifiant donc très complexe pour un résultat nul) , le seul truc que tu pourra faire sont les chose basique , mais on en fait le tour rapidement ( je doute qu'on bloque sur l'affectation ou la comparaison en assembleur).

[Obsidian]

Bonjour,

… et inutile si l'on ne souhaite pas faire de programmation système mais uniquement de l'applicatif.

Si tu veux faire de « l'applicatif » sous un OS récent, ça passe forcément par la programmation système.

1) Les codes exemples sont pratiquement tous a exécuter en mode réel, ce qui est rebutant pour un débutant.

En principe, non. Sur PC, le mode réel est quand même ce qu'il y a de plus simple. À part, la gestion des segments qui rebutent les gens autant que les pointeurs en C mais qui, tout comme eux, deviennent triviaux dès lors qu'on a compris de quoi il s'agit.

Sa serai sympa de développez si vous le désirez bien. Une option de as ???

ben une recherche sur google et tu aurait trouvé pour la syntaxe intel.

Mais voici un exemple de code sur un code C que j'avais fait pour testé (il y a quelque variable):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
asm( ".intel_syntax noprefix;" );
    …
    asm( ".att_syntax noprefix;" );

Surtout quand c'est écrit en clair dans le commentaire #10 : http://www.developpez.net/forums/d14...d/#post7996912

Mais faire de assembleur sur du C sous linux n'a aucun intérêt , vu que tu n'aura pas accès au matériel(si je me trompe pas sur linux seul le kernel a le droit donc cela veut dire rebooter a chaque fois en le modifiant donc très complexe pour un résultat nul) , le seul truc que tu pourra faire sont les chose basique , mais on en fait le tour rapidement ( je doute qu'on bloque sur l'affectation ou la comparaison en assembleur).

Luke Spywoker : si tu veux VRAIMENT tripoter les ports d'entrée-sortie sous Linux depuis un processus utilisateur ordinaire, regarde ioperm() et iopl(). Ça demande évidemment d'être root au moment de l'obtention des droits, quitte à redescendre ensuite vers l'utilisateur ordinaire. Sache aussi que ce n'est absolument une manière normale de travailler sous Linux ni sous aucun système multitâche en mode protégé : tous tes périphériques sont partagés entre les différents utilisateurs et doivent être gérés en coopération avec tous les autres (impossible, par exemple, de rester monopolisé sur un seul périphérique le temps qu'il finisse sa tâche. C'était particulièrement vrai avec les lecteurs de disquettes).

Ensuite, installe DosBox quand même, c'est vraiment ce qu'il y a de plus facile à faire : tu l'installes et tu la lances. Tout est configuré pour toi dès le départ. Tu n'es même pas obligé d'écrire tes programmes à l'intérieur de l'émulateur : comme il s'agit d'un répertoire partagé, tu écris tes programmes avec ton éditeur habituel, et tu déposes tes fichiers dans le répertoire en question. Ils seront immédiatement visibles depuis ta sessions DOS.

Enfin, crée une VM. Cette VM, soit tu la laisse vierge, soit tu lui installes une mini-distribution de Linux. Dans les deux cas, ça te permettra d'écrire des programmes assembleur amorçables. À ce moment, quand aucun système d'exploitation ne sera encore chargé, ça te permettra d'avoir ton ordinateur pour toi tout seul et de faire fonctionner des programmes mono-tâche en 32 ou 64 bits avec accès total au matériel comme au temps du DOS. Par contre, il y aura tout à faire, à commencer par initialiser proprement le mode protégé, voire le flat mode. C'est passionnant mais ça demande du boulot.

L'avantage de la VM est d'éviter de travailler sans filet : tu pourras tranquillement provoquer des crashs sans risquer de perdre le contenu de tout ton disque dur ou pire. Ça te permettra également de lancer plusieurs fois le même programme au fur et à mesure que tu le mettras au point sans avoir à redémarrer à chaque fois, ce qui devient vite ingérable.

[chrtophe]

@luke spywalker

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

.intel_syntax noprefix

[Obsidian]

@luke spywalker

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

.intel_syntax noprefix

On l'a dit trois fois, déjà ! Merci de bien relire le fil avant de poster…

[Luke spywoker]

Merci pour vos réponses éclairées,

vous avez raison, faire de l'assembleur, que je définis comme applicatif, se résumerai a faire des appels au binding de la libc ou de faire des appels système.
Donc coder le programme directement en C est une solution préférable, ça éviterai de devoirs chercher les tailles des types des membres des structures dans les sources, etc...

Mais ma petite expérience de l'assembleur me sera toujours utile comme:

Ecrire 95 % du programme en C et implémenter les algorithmes gourmands en assembleur.

Me semble être une bonne approche.

Il suffit que je trouve le moyens de connecter le fichier produit par l'assembleur qui devra sûrement être un fichier objet *.o, au code écrit en C et surtout trouver comment appeler la|les fonctions écrit en assembleur depuis le programme écrit en C.

Sans compter que connaître la syntaxe assembleur permet aussi d'autres choses comme mieux comprendre gdb ou même le fonctionnement d'un ordinateur si l'ont s'intéresse au matériel.

Par contre je ne comprend toujours pas l'intérêt du mode réel:
1) L'on a pas accès a ce mode depuis l'OS.
2) Les valeurs des IO ports peuvent être variables malgré leurs standardisation qui est de moins en moins respectées d'après mes sources comme le USB.
C'est la programmation du matériel.
Mais comme je l'ai déjà dit sous Linux la programmation système se fait avec le GNU C qui une variante du C utiliser dans le kernel.
Et comment accéder a ce mode si l'on veut s'en servir ?
Mais le mode réel est réserver a la programmation système, dont je doute être capable.

Merci pour les liens concernant ioperm() et iopl().

Note: ont peut tester du code noyau en l'introduisant dans le noyau sous forme de module, avec la commande insmod, sans devoir rebooter, j'en connaît qui n'ont pas lu mon tutoriel.

Bref passer 3 semaines a étudier l'assembleur ont été et seront bénéfique.

Je crois qu'on peut dire que:
1) La syntaxe et les instructions sont facile a assimiler car le langage est très logiquement construit et il y en a pas beaucoup.
2) Pour construire un programme digne de ce nom c'est le contraire, il faut écrire beaucoup de code, tester tout ce code.
3) Dommage de ne pas avoir de traceback quand ça plante: juste le message segmentation fault.

Je ne pense pas aller plus loin que ce que j'en sais actuellement sur l'assembleur: mais cette expérience aura grandement contribuer a ma culture informatique.
Merci a tout le monde pour votre aide.

[Obsidian]

Il suffit que je trouve le moyens de connecter le fichier produit par l'assembleur qui devra sûrement être un fichier objet *.o, au code écrit en C et surtout trouver comment appeler la|les fonctions écrit en assembleur depuis le programme écrit en C.

Comme cela a été dit dans une autre discussion, il faut déclarer les bonnes sections (spécialement .text) et exporter les symboles qui servent de point d'entrée à tes procédures. Ensuite, ça se fait avec le linker « ld ».

Sans compter que connaître la syntaxe assembleur permet aussi d'autres choses comme mieux comprendre gdb ou même le fonctionnement d'un ordinateur si l'ont s'intéresse au matériel.

Connaître l'assembleur, assurément oui. La syntaxe, en revanche, n'est que secondaire.

Par contre je ne comprend toujours pas l'intérêt du mode réel:
1) L'on a pas accès a ce mode depuis l'OS.
2) Les valeurs des IO ports peuvent être variables malgré leurs standardisation qui est de moins en moins respectées d'après mes sources comme le USB.
C'est la programmation du matériel.
Mais comme je l'ai déjà dit sous Linux la programmation système se fait avec le GNU C qui une variante du C utiliser dans le kernel.
Et comment accéder a ce mode si l'on veut s'en servir ?
Mais le mode réel est réserver a la programmation système, dont je doute être capable.

Le mode réel est le mode originel de fonctionnement des x86. Le 8086 ne sait fonctionner que comme ça. Le mode protégé est une sophistication qui est venue s'ajouter, sur les modèles suivants, aux mécanismes déjà en place pour répondre aux nouveaux besoins, devenus impérieux avec le multitâche et avec la complexification du développement logiciel.

On n'a pas accès à ce mode depuis un OS… en mode protégé ! Tu peux tout-à-fait utiliser, en revanche, un OS en mode réel. C'est le cas du DOS qui a régné sur le monde du PC avant Windows et, pour être honnête, jusqu'à Windows 98. Il a l'avantage d'être simple, très documenté, et c'est dans cet environnement que tu trouveras le plus d'informations sur la programmation en assembleur sur PC. En mode 16 bits, par contre, malheureusement.

Merci pour les liens concernant ioperm() et iopl().

N'en abuse pas. C'est dangereux et c'est sale. Si ça ne fait pas planter ton ordinateur, ça perturbera quand même les pilotes légitimement en place.

Note: ont peut tester du code noyau en l'introduisant dans le noyau sous forme de module, avec la commande insmod, sans devoir rebooter, j'en connaît qui n'ont pas lu mon tutoriel.

Je ne sais pas à qui tu t'adresses en disant cela mais je développe sous Linux depuis 1998 et ai soumis plusieurs patches qui font désormais partie du tronc principal (même si la plupart n'interviennent que sur la forme). Je sais comment fonctionne le noyau. L'idée était d'une part de t'inciter à développer sans noyau ni OS si tu veux vraiment aller au fond des choses et, d'autre part, de te faire prendre conscience qu'un programme qui plante dans le noyau, y fût-il entré via insmod ou par recompilation initiale, ne vont pas engendrer une segfault ou un signal mais feront au mieux freezer ta machine, au pire provoqueront des corruptions de données.

Mais soit. Je ne suis pas un grand utilisateur de VM de toutes façons moi non plus. Je te laisse faire ta propre expérience. Sache tout de même que tu auras quand même une solution de repli quand cela deviendra trop pénible de redémarrer à chaque fois.

3) Dommage de ne pas avoir de traceback quand ça plante: juste le message segmentation fault.

Tu peux si tu as construit une table des symboles. D'un autre côté, les symboles de déboguage servent surtout à faire le lien entre les adresses du programme en langage machine en train d'être exécuté et les lignes du fichier source. Quand tu débogues un programme écrit en assembleur, il reste à peu près équivalent à ce que tu as écrit. Mais c'est quand même mieux avec une backtrace, certes.