Est-ce possible de faire un programme en assembleur soit exécutable sous n'importe quel OS ? car l'assembleur appartient au processeur et un processeur c'est indépendant du OS, je ne parle pas ici de format d'exe des OS, comme exe, com, etc mais juste du code en tant que tel. Mais un truc que je trouves bizarre c'est que les interruptions DOS peuvent être mise dans un code asm, intel serait avec Microsoft ?? en clair existe t'il une norme x86 asm qui exclut toute instructions non standard x86 comme 21h de DOS et qui fait qu'on peut coder seulement avec un standard x86, admettons un fichier qui contient uniquement (en code machine bien sûr pour que ce soit exécutable) MOV EAX, EBX
 
donc si j'exécute ce fichier txt qui contient uniquement cela, je devrais pouvoir l'exécuter autant sous windows, linux, solaris, etc ? non ? sinon cela veut dire que l'assembleur est dépendant du OS et là je comprends pu rien  

oulala c'est vieux tout ca pour moi (au moins 10 ans)
>Est-ce possible de faire un programme en assembleur soit exécutable sous n'importe quel OS
non, deja le processeur ne comprend pas de l'assembleur : il faut le transformer en code machine. Il se trouve que l'asm est ce qui se rapproche le plus de code la.
de plus , si tu es sous un os, il faut que l'os sache que ton programme est un fichier executable (et non pas un fichier texte). Generalement, c'est parce que ton fichier a une certaine extension ,un certain header (header qui suivant l'os sera different) et respecte des conventions propre à l'OS
 
>Mais un truc que je trouves bizarre c'est que les interruptions DOS peuvent être mise dans un code asm, intel serait avec Microsoft  
ca ne serait pas plutot l'inverse ? Intel a donné ces spec ; microsoft les a suivies. L'interruption DOS n'est elle pas uniquement l'int 21h ? si c'est le cas, je pense que le terme d'interruption DOS a été donné par abus de language. Un autre OS aurait pu utiliser l'int 21h pour tout autre chose
 
 
EDIt : d'ailleurs Harkonnen dans un autre de tes posts a repondu à la 1ere question

si tu écris une routine asm optimisée, elle sera réutilisable sous windows 95+, linux, etc.... (fo que le code soit qd même même indépendant de l'os et soit fait pour le mode protégé)

Voilà, comme dit bjone, il faut que le bout de code en question soit suffisament bien construit pour eviter de taper n'importe où car si sous DOS ça passe encore à peu près, sous les OS utilisant le mode protégé, tu as vite fait de declencher une exception.
 
Le problème de ton bout de code c'est qu'il va être executé dans un environnement qui ne va pas réagir de la même manière en fonction de ce qu'il se passe sur la machine.

 
Mais tu auras acces a rien... pas de fichiers, pas de périphériques, pas de son, pas d'image... en fin de compte la seule chose que tu puisses faire c'est des calculs.

c'est surtout que le CPU est indépendant de l'OS et que chaque OS propose ses propres services pour la gestion du disque (fichiers), de la mémoire, de l'affichage etc.  Bref les OS ne sont pas compatibles entre eux et c'est là que le bas blesse.
 
Donc rien que pour afficher quelque chose, tu dois avoir une routine pour chaque OS.
 
Si tu veux un prog dont le source est compilable pour n'importe quel OS sans (grosses) modifications, change de langage.

le BIOS est construit pour le CPU et contient du code de gestion du disk dur, du  
 
clavier et de la carte vidéo en mode VGA standard.
Ce code "interruption, plage 0 a FF) peut être réutilisé.
en clair, cela veut dire que tu peut compiler un programme en assembleur, faire une  
 
disquette bootable, coler ton programme dessus et cela démarre.
Magique non.
d'ailleurs c'est comme cela que démarrent tous les ordinateurs du monde  
 
!!!!!!!!!!!!!!!!!.

certainement pas.

Je poursuis un peu le topic...
 
Le code est généralement fonctionnel sur tous les OS.
Mais attention, il y a deux façons de faire de l'asm pour x86 - le format intel et at&t.
 
Et puis, il faut faire correspondre les appels à partir du code C, la gestion de la pile peut être un peu différente...
 
Bref, faire un code fonctionnant sous GCC et sous VisualC, c'est du boulot. On remercie donc les commandes préprocesseur à utiliser avec abus !!!
 
Ensuite le mode protégé : Sous DOS, on tourne en mode réel (sauf DJGPP, DOS4GW...), sous Windows, Linux... on tourne en mode protégé avec des descripteurs généralement initialisés sur 4Go (virtuel et géré par le noyau)... Ainsi, SS, ES, DS, GS et FS n'ont pas besoin d'être initialisés. Enfin, ne jamais modifier SS ni ESP !!! car alors que sous DOS, on peut faire un cli/sti, cela n'est pas permis dans les autres OS.
 
Je passe pour le reste...
 
Maintenant les interruptions... C'est du DOS ! Donc à oublier sous Windows, Linux...
 
 
Donc pour conclure, et pour revenir sur le codage x86, il existe deux normes (couramment utilisés), la AT&T et l'Intel :
 
La première (AT&T) utilisée par les compilateurs GCC utilise un code mnémonique plus compréhensible (subjectif)
La syntaxe (généralement) : [instruction et type] [source] [,[destination]]

 
La seconde (Intel) est utilisée par les compilateurs Microsoft, Borland et Intel (sic!).
Sa syntaxe : [instruction] [type][destination] [,[type][source]]

 
Je termine par un peu de réflexion :
Faire un code assembleur c'est bien mais optimisé un algorithme c'est beaucoup mieux ! Avant de passer à l'assembleur, il faut toujours se poser la question, mon code "assembleur" sera-t-il réellement plus rapide que mon code "c" optimisé ? Pas si sûr...
 
Vous voulez un bon livre ? Voyez Michael Abrash, un des meilleurs optimiseur ! => Le zen de l'optimisation
 

 
Mais comment l'OS communique avec le hardware?

En direct !
I/O, mem, IRQ

 
on parles des interruptions en tant que services de l'OS.

 
Ah, ok; Les interruptions matérielles continuent d'etre utilisées alors? Meme en mode protégé?

Soit pas grand chose de plus qu'avec un langage de plus haut niveau...

Ben oui, les IO ports aussi. Que ce soit physique (y'a pas le choix c'est hardware : périphérique, division par zéro, ...) ou logique (les appels système se font via int 0x80 sous Linux, Windows commute en mode kernel via une it aussi).

 
Ben non, ce serait plutot des choses en moins en l'occurence!

java...

Je voulais pas blesser Harko.

 
vi par les pilotes qui travaillent au même niveau de privilèges que le noyau...

pas si sûr...sous NT la HAL s'en occupe...
Même en mode user, des it sont utilisées. Par exemple, le mode Debug de compilation truffe ton code de int 0x3 qui est l'it de break point.

vivi, sous nunux sur un x86, c'est l'int 80h qui expose les services de l'os...