Discussion :

[kripteks]

Salut à tous.
J'aimerais débuter en assembleur pour faire des applications fonctionnant sur linux (tournant sur des processeurs i386 et amd64).

Du coup, l'application que je ferais sera-t-il fonctionnel sur tous les processeurs i386 et amd64 ? ou je devrais être encore plus ciblé sur les processeurs ?

[Forthman]

bonjour,

quand tu dis "faire des applications" tu penses à quoi ?

si tu fais un programme sous linux x86 32bits , il fonctionnera sous linux x86 32 bits.

[Obsidian]

Bonjour,

Salut à tous.
J'aimerais débuter en assembleur pour faire des applications fonctionnant sur linux (tournant sur des processeurs i386 et amd64).

Pour préciser la question de Forthman, le langage de prédilection pour développer des applications sous Linux est le C, car c'est un langage dont l'histoire est intimement liée à celle d'Unix en général (les deux ont été conçus par les mêmes personnes). Maintenant, si tu veux vraiment faire de l'assembleur, et travailler sous Linux, alors il existe un certain nombre de solutions. Les plus courantes sont soit NASM ou FASM, soit l'utilisation de l'assembleur historique UNIX « as », soit encore l'insertion d'assembleur inline au sein d'un programme C.

Du coup, l'application que je ferais sera-t-il fonctionnel sur tous les processeurs i386 et amd64 ? ou je devrais être encore plus ciblé sur les processeurs ?

A priori, oui. Le 64 bits est effectivement un « nouveau » mode, différent du premier même s'il en reste très proche. Par contre, comme dit juste avant moi, les processeurs x86 64 bits sont conçus pour être compatibles avec les 32 bits. Donc un programme 32 bits fonctionnera sur un microprocesseur 64.

[kripteks]

Merci pour les réponses.

Les applications en question, un par exemple:
- inclure quelque fichier C utile comme SDL pour créer une fenêtre (et ajouter un contexte opengl)
- faire de l'opengl
- récupération des données d'un fichier (notamment je penses pour la partie souris/clavier) (même si SDL le propose aussi, je veux juste la tester manuellement)



Ma crainte était que le code ne fonctionnera pas sur tous les variantes processeur (qui sont utiliser par le publique actuel).

Depuis wikipédia:
Gammes actuelles
x86-32: EP80579 · Atom
x86-64: Atom · Celeron · Pentium · Core i3 · Core i5 · Core i7 · Xeon
Autres: Itanium

Donc, si je fais un code pour du x86-32, il fonctionnera automatiquement sur les x86-64 comme: Core i3 · Core i5 · Core i7 qui sont généralement utiliser par le publique.



Là se pose la question, vaut-il mieux faire une version pour chaque type ou laisser en 32 bits ?
Je vais chercher sur google.

[Obsidian]

Merci pour les réponses.

Les applications en question, un par exemple:
- inclure quelque fichier C utile comme SDL pour créer une fenêtre (et ajouter un contexte opengl)

Les include C ne sont pas des imports de packages ou de bibliothèques. Ce sont des fichiers C à l'intention du compilateur qui lui expliquent comment se servir d'une bibliothèque déjà compilée. Inclure cela dans un autre langage n'a aucun intérêt.

- faire de l'opengl
- récupération des données d'un fichier (notamment je penses pour la partie souris/clavier) (même si SDL le propose aussi, je veux juste la tester manuellement)

Faire de l'OpenGL en assembleur, il faut être très motivé ! Mais c'est faisable.
Le problème étant que, comme d'habitude, l'API d'OpenGL est en C. Donc, pour l'appeler depuis des programmes 100 % assembleur, tu vas être obligé de reconstruire manuellement tous les appels de fonction, ou à la limite utiliser INVOKE. Ça, ça passe encore, mais manipuler et renseigner à la main tous les objets de type structure, ça, ça ne sera pas une sinécure.

Récupérer des données dans un fichier, en revanche, c'est déjà nettement plus dans les cordes d'un programme totalement en assembleur. Ça a même beaucoup d'intérêt puisque cela consiste à aller manipuler les appels système.

Là se pose la question, vaut-il mieux faire une version pour chaque type ou laisser en 32 bits ?
Je vais chercher sur google.

En fait, c'est une des nombreuses raisons pour lesquelles on utilise surtout les langages de plus haut niveau : pouvoir recompiler les applications sur n'importe quelle architecture (y compris les non x86) sans avoir à réécrire le programme.
Sinon, si tu tiens à les développer en assembleur, ça dépend essentiellement de ce que tu veux faire toi-même : si tu comptes diffuser tes créations au plus grand nombre, alors le 32 bits reste obligatoire, et réécrire deux fois la même chose risque de passablement te faire suer. Si c'est pour apprendre sérieusement l'assembleur x86, tu devras également maîtriser le 32 bits avant de passer au 64 (on commence juste à se débarrasser du D.O.S. et de la programmation 16 bits, hors d'âge). Si tu veux faire de l'optimisation avancée et surtout découvrir les arcanes de ta machine, tu peux te permettre de partir directement sur le 64.

[kripteks]

Je comprend.

Moi qui me disait que de simple include et call aurait suffit que c'est juste la syntaxe (d'assembleur) qui sera un peu dure, mais sa semble pas être si simple.
Et étant aussi débutant, je risque vite de me cogner au mur avec mes objectifs haute.

Du coup je me dis que je pourrais faire inversement, faire de base sur C mais (après une certaine stabilité de la base du projet et sur le niveau d'assembleur que j'aurais acquis) je pourrais remplacer un maximum de parti C en assembleur là où il serait possible et utile d'en mettre et ainsi prévu portable.

[Obsidian]

Je comprend.

Moi qui me disait que de simple include et call aurait suffit que c'est juste la syntaxe (d'assembleur) qui sera un peu dure, mais sa semble pas être si simple.

C'est-à-dire que ce n'est pas le même langage. Il ne s'agit pas faire une traduction littérale d'un mot-clé vers un autre, sinon cela n'aurait aucun intérêt en soi.
Il ne s'agit pas non plus d'un langage « concurrent », comme le Pascal ou le C, par exemple. C'est le jeu d'instruction du micro-processeur, et c'est sur lui que sont basés tous les autres.

C'est aussi cela qui le rend passionnant, et presque nécessaire si on a envie non seulement de savoir comment tout cela fonctionne, mais également si on souhaite un jour développer sur d'autres plateformes que nos PC habituels et estimer globalement quelle est la puissance maximale théorique que l'on pourrait tirer de sa machine.

Et étant aussi débutant, je risque vite de me cogner au mur avec mes objectifs haute.

Il n'y a pas de mal à être ambitieux en soi. Par contre, il ne faut pas brûler les étapes sinon tu auras perdu au final beaucoup de temps pour rien.

Du coup je me dis que je pourrais faire inversement, faire de base sur C mais (après une certaine stabilité de la base du projet et sur le niveau d'assembleur que j'aurais acquis) je pourrais remplacer un maximum de parti C en assembleur là où il serait possible et utile d'en mettre et ainsi prévu portable.

Ça dépend. Ayant débuté sur 8 bits (à une époque où c'était beaucoup plus facile), j'ai appris l'assembleur avant le C et ça a grandement facilité les choses. L'approche « bottom-up », c'est-à-dire voir les choses dans l'ordre en partant du début et en « remontant » vers l'état actuel de l'art, est toujours la meilleure méthode. Ça pose simplement problème lorsque le chemin parcouru est déjà long et qu'il devient humainement difficile de le parcourir en entier.

D'autre part, à l'époque, on faisait beaucoup d'assembleur, et les routines de bas niveau (comme le BIOS) étaient conçues pour être appelées depuis des programmes assembleur également. Notamment avec l'usage des interruptions qui rendaient les appels système très concis. Aujourd'hui, on s'appuie quasi-exclusivement sur des bibliothèques sous-jacentes, elles-mêmes quasi-exclusivement écrites en C, et les interfaces fondamentales comme l'UEFI qui doit remplacer le BIOS commencent à l'être aussi. On est donc obligés de cohabiter avec API et ABI conçues pour le C et ça rend les choses compliquées, naturellement.

Si tu as la chance de travailler également sur des petits systèmes, c'est-à-dire soit des platines de simulation, soit des micro-contrôleurs, soit encore les anciens ordinateurs huit bits des années 1980, tu auras une vision beaucoup plus épurée de la chose et ça te permettra de t'immerger facilement sur les bâtiments que sont devenues les machines à base de x86.

[CP / M]

Là se pose la question, vaut-il mieux faire une version pour chaque type ou laisser en 32 bits ?
Je vais chercher sur google.

Attention toutefois, comme dit précedemment, un processeur 64b peut faire tourner du code 64b, mais si tu veux appeller des librairies depuis un programme 32b sur un OS 64b, tu dois avoir les versions compilées en 32b de ces librairies. En effet, les conventions d'appel de fonction on été modifiées sous Linux entre 32 et 64b.