Question sur assembleur

Programmation
#1

Salut à tous,
Je me curiosite sur l’assembleur en ce moment :smiley:

(En y connaissant rien en assembleur):
Comment est-il la portabilité du code niveau processeur ?

J’ai lu qu’un code écrit pour X processeur ne fonctionne pas sur l’autre.

De même j’ai lu aussi, qu’on peut codé pour un processeur mais qui peux fonctionner sur ses supérieur ect

Avez-vous des connaissances ?

Y a t il une différence (niveau codage assembleur) entre les proc. intel et amd ?

Voici un petit bonus que j’ai apprécié après avoir vu une dizaine de projet d’assembly mini os qui boot simplement sans faire grand chose, mais celle-ci, chapeau: menuetos.net/index.htm

Encore un peu de l’hors sujet mais pas trop:
Les futures processeurs qu’on utilisera pour nos bureaux ect seront de quel type ? x86,amd64,(intel128?:p),…

#2

L’assembleur n’est pas du tout portable (enfin, dans le sens où du C, par exemple, est portable).
Non seulement les instructions sont spécifiques à une famille de processeurs donnée, mais en plus t’es dépendant des conventions d’appel du système et autres joyeusetés (comment je passe les paramètres à une fonction etc).

Clairement, de l’assembleur Intel ne fonctionnera pas sur du Motorola ou sur du Sparc.

Par contre il y a une compatibilité à l’intérieur d’une même famille de processeurs (x86 / x64 par exemple). À quelques rares exceptions près les nouveaux processeurs d’une famille donnée supportent les jeux d’instructions précédents et ne font que rajouter d’autres instructions.
La différence entre x86 et x64 c’est surtout qu’un nouveau jeu d’instructions 64 bits a été rajouté, alors que le x86 ne gérait que le 32 bits (et uniquement le 16 bits du 8086 jusqu’au 80286).
Par exemple, du code 32 bits prévu pour un 80386 tourne sans souci* sur le dernier Intel Machin Bridge, mais l’inverse n’est pas forcément vrai si tu utilises des instructions spécifiques qui n’existaient pas dans les versions précédentes.
(*) uniquement en ce qui concerne le CPU hein, pour le matériel autour c’est une autre histoire.

Au niveau compatibilité Intel / AMD, la vaste majorité des instructions sont communes mais chaque fondeur a aussi développé des instructions qui lui sont propres. Franchement je sais plus trop où ça en est avec leurs bidules qui changent sans arrêt, en tout état de cause quand incompatibilité il y a c’est sur des instructions très spécifiques. Le mieux c’est de choper les manuels de référence des jeux d’instructions Intel et AMD, et de comparer.

#3

Le principal c’est des extensions qu’ils ajoutent (SSE1, SSE2, SSE3, etc pour Intel).

Tout cela peut être intéressant pour les développeurs qui écrivent du code compilé nativement (C, C++, Objective-C, ADA, fortran, etc) car ça explique pourquoi il peut être important de donner au compilateur le maximum d’information sur l’architecture cible, afin que celui-ci utilise au maximum les possibilités du processeur (tout en sachant qu’il perd la compatibilité avec d’autres machines).

C’est en partie ce qui explique le système de port des BSD, le système de package de Gentoo (et dérivées) et les outils de compilations comme apt-build, certains cherchent à compiler tout leurs logiciels (ou une partie d’entre eux) pour gagner en performance (ce n’est pas forcément très probant).

#4

Bonjour et merci pour les réponses.

Donc lorsqu’on veut faire un logiciel en asm, on peut le faire directement pour une famille x86 ou amd64 et tous les processeurs de cet famille sera compatible avec ce code.

Et encore une question:
L’assembleur est lié au processeur, mais quoi d’autre ?

#5

Je pense, mais un connaisseur pourra confirmer, que c’est lié aussi au format de binaire utilisé pour le système d’exploitation. Sous linux on prend généralement les ELF, mais il y en a d’autres : a.out, COFF, PE, etc

#6

Le format des binaires joue dans la mesure ou certains formats impose du code repositionnable alors que d’autres autorisent du code à adresse fixe avec tables de correction générées par le compilateur.

D’autre part l’assembleur est fortement lié à l’OS lui-même (appels aux libs du système), c’est encore plus visible que pour d’autres langages bas niveau comme le C. Non parce qu’il faut pas croire que juste parce que tu fais de l’assembleur alors d’un coup tu vas pouvoir accéder directement au matériel sans passer par l’OS. :wink:
Le gros point d’incompatibilité à part le processeur reste quand même les conventions d’appel : ordre des paramètres sur la pile, responsabilité de nettoyage de la pile au retour de fonction, utilisation des registres (paramètres, valeurs de retour, écrasement, conservation) etc.
Voir ce document pour se faire une petite idée (ça concerne principalement les compilateurs C++ mais ça inclut aussi des infos sur les conventions C) : agner.org/optimize/calling_conventions.pdf

#7

Hmm, voila que tu me dis que l’assembleur est dépendant de l’os :017

Mon but était de faire quelque chose de bootable indépendant de l’os, qui normalement discute avec le processeur, la mémoire, les autres matériels pour arriver à ces fins.

Pour un exemple:
netinstall de debian. Il est bootable, il fait des actions ect.

Pour un exemple plus simple:
un cd bootable, une fois démarrer dessus, nous sort une calculatrice où l’on peut faire des calcule (valeur entré par clavier).

Pour y arriver à quelque chose comme cela, quel langage me faut-il ?

édite:
J’ai retrouver cet os: menuetos.net/, si l’on croit à la description, il a été écrit totalement en assembleur sans se baser sur un os.
Donc il est possible de faire fonctionner le code assembleur sans passer par un autre os ?

#8

[quote=“kripteks”]Hmm, voila que tu me dis que l’assembleur est dépendant de l’os :017

Mon but était de faire quelque chose de bootable indépendant de l’os, qui normalement discute avec le processeur, la mémoire, les autres matériels pour arriver à ces fins.[/quote]
Aaah je croyais que tu voulais “juste” coder en assembleur sur un OS pré-existant, sans réinventer la roue. :wink:
Au temps pour moi.

Et bon courage, au passage. Discuter directement avec le matériel c’est la misère, va falloir être motivé. :mrgreen:

[quote=“kripteks”]Pour un exemple plus simple:
un cd bootable, une fois démarrer dessus, nous sort une calculatrice où l’on peut faire des calcule (valeur entré par clavier).

Pour y arriver à quelque chose comme cela, quel langage me faut-il ?[/quote]
Si tu poses la question en termes de courbe d’apprentissage, je te répondrai : un LiveCD Debian (customisé à mort avec live-build et consorts) et le langage de ton choix. :stuck_out_tongue:
Cadeau Bonux : ncurses, framebuffer si t’as envie, que du bonheur.

L’installeur Debian, ce n’est “que” ça : un bootloader déjà tout prêt qui lit un fichier de configuration, un kernel Linux, et des programmes en C / C++ / Perl / Python / whatever.

#9

:041 c’est donc possible.

C’est sûr sa va pas être une partie facile, mais je suis bien motivé, et c’est lié un peu à mes études, en plus d’aider mes études, sa pourrait me servire dans ma profession et/ou pour mon plaisir un peu à la hackday(.com), donc ici j’ai aucune perte de temps inutile à vrai dire.
J’ai mon diplôme d’électricité en poche et là je suis une étude d’électronique (orienté médical), j’ai vraiment pas mal de cours basé sur les 0 et 1 !

#10

Cela dit, les problématiques de conventions d’appel il va falloir que tu y penses toi aussi pour en mettre une en place. Sinon ton code va vite devenir un joyeux bordel, et tu ne pourras rapidement plus toucher à rien sans tout faire sauter.

Aussi, comme tu n’auras aucune couche d’abstraction matérielle (et que tu ne vas certainement pas en développer une correcte à toi tout seul dans un temps raisonnable), il te reste… le BIOS. Assembleur 16 bits (rien que le trampoline pour passer en 32 bits est une horreur à coder), modèle mémoire segmenté, … Welcome back to the 80’s. :smiley:

Dernière chose pour le moment, teste en machine virtuelle, ça t’évitera de faire des bêtises sur du vrai matériel (et accessoirement t’auras pas à rebooter ta bécane à tout bout de champ). :wink:

#11

Ah oui, pour les reboot à tout bout, j’avais lu aussi, et je m’étais pencher sur une idée: 2 ordinateur (qui consomme vraiment très peu).
Une pour la documentation, les sauvegardes, tous les fichiers ect. qui sera toujours ouvert comme ordinateur principale et une pour la partie pratique pour les testes ect.

#12

[quote=“kripteks”]Ah oui, pour les reboot à tout bout, j’avais lu aussi, et je m’étais pencher sur une idée: 2 ordinateur (qui consomme vraiment très peu).
Une pour la documentation, les sauvegardes, tous les fichiers ect. et une pour la partie pratique.[/quote]
Bof, autant rester sur une VM sur ton poste de dév : tu peux intégrer la construction de l’ISO dans ton processus de compilation, ta VM étant déjà paramétrée pour utiliser cet ISO y’a plus qu’à la démarrer (ou encore mieux la redémarrer).
Avec VirtualBox tu peux même intégrer le (re)démarrage lui-même de la VM dans ton processus de compilation, ça se contrôle aussi en ligne de commandes.

#13

Et y aura-t-il pas de différence entre le fonctionnement sur une machine réel et virtualisé ?

#14

Ben tu sais, VirtualBox arrive à faire tourner Linux, BSD, Windows, DOS etc à l’aide d’un principe très simple : se comporter comme se comporterait du matériel, et ne pas réellement s’occuper de ce que l’OS fait.

Je doute fort que ton programme en assembleur arrive à trouver un recoin bizarre qu’aucun de tous ces OS ne couvrirait déjà, et qui ferait que le matériel virtuel se comporte différemment d’un équivalent physique. :wink:

#15

C’est noté.
Je vais débuté à assembleur tranquillement.

#16

Une façon raisonnable de discuter avec le matériel est d’étudier le BIOS. Celui ci fournit des routines primaires mais efficaces pour accéder au matériel (disques, clavier, ecran). L’appel était dans le temps fait par des interruptions logicielles ce qui permettait une portabilité minimale du code (et qui permettait aussi de «déplomber» simplement les protections des programmes, heureux temps des int 10h, int 13h, etc). Je te suggère de te plonger dans les docs des BIOS par exemple ceux fournis avec VirtualBox ou Qemu genre bochsbios ou openbios)