Discussion :

[artha77]

Bonjour,

j'ai une question qui m'est venue en commençant à apprendre les assembleurs : comment un programme, écrit en C par exemple, peut-il fonctionner sur un ordinateur avec un processeur de la famille x86, et sur un autre avec un processeur ARM (bon c'est peu probable ok, mais un Raspberry Pi par exemple qui a un processeur ARM). Comment un programme que j'exécute sur mon PC perso avec un i5 fonctionne aussi sur mon Raspberry Pi avec un processeur ARM, qui n'ont pas la même façon de faire ? Sur des processeurs de la même famille et avec un fonctionnement relativement similaire, je peux comprendre, un peu comme si à chaque processeur c'était des mises à jour qui rajoutaient des instructions ; il suffirait de s'en tenir aux instructions les plus basiques pour être compatible avec tout. Mais là c'est carrément 2 manières de faire différentes, et pourtant au final on n'a qu'1 seul exécutable produit ; imaginons que je code en assembleur pour des processeurq avec une architecture.

Bon je suis loin, très loin d'être expert dans le domaine, donc désolé si je dis des choses stupides, si j'emploie des termes inappropriés ou autres, mais justement je veux apprendre comment fonctionnent la machine, le processeur, le langage machine et les assembleurs, donc si au passage vous avez des liens à me passer pour apprendre tout cela, ou même me conseiller sur l'ordre dans le quel procéder pour apprendre (commencer par le fonctionnement intime d'un processeur porte logique, etc. ou par de l'assembleur direct, enfin vous voyez ). Si vous connaissez des livres qui sont très bons sur le sujet, ou des videos, bref toute ressource qui puisse m'aider , ou même si l'un de vous aurait l'envie et la gentillesse de me passer son Skype, ou tout autre moyen de communication pour partager, échanger, discuter avec moi... Le savoir est inestimable après tout, donc ce serait cool. J'aime savoir comment fonctionnent les choses au niveau le plus fondamental, pas forcément pour réinventer la roue, mais pour mieux l'utiliser, et juste par simple envie de connaissance. Après tout, faut-il une raison pour vouloir savoir ?

Merci d'avance en tout cas

[jlliagre]

Le programme écrit en C peut fonctionner sur diverses architectures quand il est compilé pour ces architectures. Le résultat de la compilation est un binaire qui n'est compatible qu'avec une archtecture donnée, il faut donc recompiler pour une autre architecture et le binaire sera différent. Il n'existe pas de binaires compatibles avec plusieurs architectures, ou plus précisément, ça n'est pas courant.

Il y avait des binaires compatibles avec les Motorola 68xxx et les PowerPC que l'on trouvait à une époque sur les Macs d'Apple.

Sous Linux, il y a eu des tentatives de produire des binaires de ce type (FatELF), mais c'est plus ou moins abandonné

[artha77]

oui donc si je comprend bien , imaginons que je crée un programme en C , que je le compile sur mon pc perso pour mon pc avec un i5 donc de la famille x86_64 si je me trompe pas ? (désolé je suis débutant ^^) et que je met se programme sur mon rapsberry avec un ARM théoriquement le programme est sensée ne pas ce lancer ?

mais dans ce cas pourquoi les programme d'aujourd'hui ne propose qu'une seul et unique version , à part bien sur des fois des version 32bit ou 64bit ? c'est rare que je vois des programme qui propose un binaire pour différente architectures , dans ce cas pourquoi ? ya t'il une suffisante compatibilité entre les architecture intel et amd pour que un seul programme puisse fonctionner sur plus ou moins 80% des processeur et que donc faire un version pour d'autre architecture soit assimilé a de la perte de temps ?

du coup j'en reviens à ma question , en théorie , comment faire pour que un binaires fonctionne sur plusieurs architecture en même temps , par exemple x86 et ARM

en tout cas merci d'avoir pris la peine de répondre

[jlliagre]

oui donc si je comprend bien , imaginons que je crée un programme en C , que je le compile sur mon pc perso pour mon pc avec un i5 donc de la famille x86_64 si je me trompe pas ? (désolé je suis débutant ^^) et que je met se programme sur mon rapsberry avec un ARM théoriquement le programme est sensée ne pas ce lancer ?

Pas seulement sensé, il ne pourra pas démarrer.

mais dans ce cas pourquoi les programme d'aujourd'hui ne propose qu'une seul et unique version , à part bien sur des fois des version 32bit ou 64bit ? c'est rare que je vois des programme qui propose un binaire pour différente architectures , dans ce cas pourquoi ?

Tu n'as pas assez cherché. Par exemple cette page de téléchargement d'unrar (trouvée au hasard) propose plusieurs dizaines d'architectures différentes.

ya t'il une suffisante compatibilité entre les architecture intel et amd pour que un seul programme puisse fonctionner sur plus ou moins 80% des processeur et que donc faire un version pour d'autre architecture soit assimilé a de la perte de temps ?

Intel et AMD utilisent la même architecture, c'est même AMD qui a défini l'architecture qu'Intel utilise en 64 bits. Un programme compilé avec les options par défaut tournera sur les deux types de CPU sans problème. On peut en revanche compiler et utilisant des instructions spécifiques à un modèle et dans ce cas, le programme ne sera plus portable.

du coup j'en reviens à ma question , en théorie , comment faire pour que un binaires fonctionne sur plusieurs architecture en même temps , par exemple x86 et ARM

Ce n'est pas possible. Ce qui est faisable est de concaténer les deux binaires et créer d'un chargeur qui choisi le bon, mais c'est un peu du bricolage, pas optimisé en terme de taille et de toute façon pas prévu dans les loaders standard de Linux.

Une autre approche, c'est d'utiliser un code intermédiaire "neutre" (pas x86 ou ARM, etc.) qui est traité par un programme natif, c'est par exemple ce que fait Java dont les même binaires (bytecode) peuvent s'exécuter sur n'importe quelle architecture, pourvu que la JVM y soit disponible.

[Kannagi]

Bon ben jlliagre a tout dit je pense.

artha77 tu veux apprendre l'assembleur pour quoi faire ?
L'assembleur ça reste un gros investissement , mais sur le forum il y a deux pensée ,une qui pense que le mieux pour apprendre l'assembleur c'est de programmer sur une vielle machine parce qu'il est facile et rapide de connaitre leur assembleur et leur architecture et de comment il fonction le NMI , IRQ , VBLANK , DMA ect , mais apres c'est sur que vouloir faire de Atari ST faut être motivé
Et l'autre et de commencé directement par du x86 , sur MS-DOS tu aura encore la possibilité de touché le matériel , sur un OS Moderne tu passera ton temps par passé par des fonction système écrite bien souvent en C.
(Ou alors tu fait un OS).

du coup j'en reviens à ma question , en théorie , comment faire pour que un binaires fonctionne sur plusieurs architecture en même temps , par exemple x86 et ARM

Impossible , ou alors tu passer par un machine virtuel ou un émulateur.
Il y a comme le dit jlliagre Java qui permet d'avoir un binaire multiplateforme , mais ce binaire est exécuter par la JVM et non par le processeur.

[artha77]

jlliagre :

Pas seulement sensé, il ne pourra pas démarrer.

donc en réalité un exécutable écrit en C en théorie ne peut fonctionner qu'avec une seule architecture définit a l'avance lors de la compilation ?

Tu n'as pas assez cherché. Par exemple cette page de téléchargement d'unrar (trouvée au hasard) propose plusieurs dizaines d'architectures différentes.

non mais oui j'en avait trouver mais c'est rare quoi , fin je trouve personellement

Intel et AMD utilisent la même architecture, c'est même AMD qui a défini l'architecture qu'Intel utilise en 64 bits. Un programme compilé avec les options par défaut tournera sur les deux types de CPU sans problème. On peut en revanche compiler et utilisant des instructions spécifiques à un modèle et dans ce cas, le programme ne sera plus portable.

ok je vois , mais par exemple il n'y a pas moyen de faire , "si le programme tourne sur x processeur alors faire la commande plus avancé , sinon faire la comande de base qui marche sur tous le processeur de la famille" ??

Ce n'est pas possible. Ce qui est faisable est de concaténer les deux binaires et créer d'un chargeur qui choisi le bon, mais c'est un peu du bricolage, pas optimisé en terme de taille et de toute façon pas prévu dans les loaders standard de Linux.

bah oui mais du coup se fameux chargeur il doit être integrer a l'OS comme il ne peut pas être multi-platforme , il doit être intégré a l'os qui lui est codé pour l'architecture utilisé , sinon sa veut dire que le chargeur est multi platforme et dans se cas le chargeur ne sert a rien , fin c'est comme sa que je vois le truc

Kannagi :

je veux apprendre l'assembleur car j'aime aller au fond des chose , comprendre comment elle fonctionne , puis aussi pour la liberté qu'offre l'asm , pour exploité au maximum le processeur et tout simplement pour le plaisir d'apprendre

[BufferBob]

donc en réalité un exécutable écrit en C en théorie ne peut fonctionner qu'avec une seule architecture définit a l'avance lors de la compilation ?

à proprement parler un exécutable n'est pas écrit en C, c'est le code source qui est écrit en langage C, et le code source est compilé (et lié aux éventuelles bibliothèques) sous forme d'un fichier exécutable contenant du code machine, ce code machine n'est compréhensible que pour un processeur spécifique et souvent pour un OS spécifique aussi (un binaire PE Windows x86 et un binaire ELF Linux x86 ne sont pas foutus pareils, sinon on appellerait Windows Linux voyeez..)

bah oui mais du coup se fameux chargeur il doit être integrer a l'OS comme il ne peut pas être multi-platforme , il doit être intégré a l'os qui lui est codé pour l'architecture utilisé , sinon sa veut dire que le chargeur est multi platforme et dans se cas le chargeur ne sert a rien , fin c'est comme sa que je vois le truc

ben tu vois mal le truc
concrètement c'est un hack qui ne fonctionne pas forcément, qui est très sale etc. le même code machine sera compris différemment par les deux processeurs et par les deux OS, ça n'est absolument pas viable pour créer des exécutables, ça n'est pas "stable", et ça demande de comprendre déjà bien le système et la programmation avant de se lancer là dessus

[jlliagre]

non mais oui j'en avait trouver mais c'est rare quoi , fin je trouve personellement

C'est aussi une question d'offre et de demande. Les développeurs fournissent des binaires pour les plateformes les plus utilisées par leur clients/utilisateurs.

ok je vois , mais par exemple il n'y a pas moyen de faire , "si le programme tourne sur x processeur alors faire la commande plus avancé , sinon faire la comande de base qui marche sur tous le processeur de la famille" ??

Il y a moyen mais ce n'est en général pas fait exactement comme çà. Le loader lie dynamiquement un exécutable avec la bibliothèque la mieux adaptée à l'architecture courante. Il y a donc plusieurs bibliothèques optimisées pour les processeurs spécifiques ciblés.

bah oui mais du coup se fameux chargeur il doit être integrer a l'OS comme il ne peut pas être multi-platforme , il doit être intégré a l'os qui lui est codé pour l'architecture utilisé , sinon sa veut dire que le chargeur est multi platforme et dans se cas le chargeur ne sert a rien , fin c'est comme sa que je vois le truc

Un chargeur est toujours intégré à l'OS, c'est indispensable pour qu'un programme puisse s'exécuter. Qu'est-ce que tu veux dire par "un chargeur multi-plateforme ne sert à rien" ?

[chrtophe]

Que se passe t'il quand tu compiles un programme C ?

Le programme est "traduit" en langage assembleur (ciblé pour une plateforme bien précise : exemple x86 ou Arm, ou autre ...), avec gcc, le compilateur de Linux, le résultat de cette transformation est visible via la commande (par défaut, cette étape n'est pas visible):

Code :

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

1
2
 
gcc -S code.c

A ce stade, le code assembleur correspond à l'architecture hôte et n'est plus portable. Ce code source assembleur est ensuite "assemblé" pour donner un fichier en langage machine appelé fichier objet, il n'est pas encore exécutable (mais presque).

Ce fichier objet est ensuite "linké" par l'éditeur de liens qui lie ton code aux bibliothèques externes utilisées par ton programme (.dll pour Windows, .so pour Linux), il ajoute également l'en-tête d'exécutable (structure PE pour Windows, structure ELF pour Linux).

Si tu tapes gcc -o mon_code mon_code.c, toutes ces étapes sont effectués les unes après les autres, tu ne vois que le résultat final : l’exécutable.

Par ailleurs, ça ne suffit pas à avoir un code entièrement portable, car tu n'utilises pas que des fonctions C de base, qui ne permettent pas par exemple de créer une fenêtre en environnement graphique. Des appels à des fonctions Windows, Linux ne pourra pas les comprendre, tout comme Windows ne comprendra pas des fonctions X Windows (mais il existe des surcouche Windows lui permettant de comprendre les fonctions X Window). Si tu fais un programme qui ne fait que lire ou écrire une chaine de caractère sur la console, il fonctionnera sans problème sur n'importe quelle plateforme ayant un compilateur C (après compilation sur la plateforme voulue bien sûr).

Si tu prends l'exemple de Qt par exemple, le code source généré avec Windows est entièrement portable sous Linux. Tu appelles des fonctions d'une bibliothèque externe au C de base (Qt). Il faudra bien entendu recompiler.

Il y avait des binaires compatibles avec les Motorola 68xxx et les PowerPC que l'on trouvait à une époque sur les Macs d'Apple.

A ma connaissance, il n'y a qu'Apple qui a fait ça. Le format universal binary a été crée lors du passage de l'architecture PowerPC vers Intel. En fait le fichier contenait 2 codes exécutables distincts, l'un pour PowerPC, l'autre pour Intel, un en-tête spécifique permettait la sélection du bon.
Quant au cas du passage du Motorola vers le PowerPC, plus ancien, (Apple ayant changé 2 fois de type de processeur) c'était le fat binary. Mais comme l'a souligné jlliagre, c'est un cas très particulier, utilisé à ma connaissance que par Apple.

[Obsidian]

Bonjour,

donc en réalité un exécutable écrit en C en théorie ne peut fonctionner qu'avec une seule architecture définit a l'avance lors de la compilation ?

Oui, mais en réalité, il faut prendre le problème à l'envers : le C a été l'un des premiers langages à se populariser et à être intrinsèquement conçu pour produire des exécutables autonomes. Et comme les autres, il a été développé justement pour pallier les limites de l'assembleur strict. Et depuis, bon nombre de langages ont fait la même chose, spécialement depuis l'explosion de l'orienté objet.

Le C reste très populaire encore aujourd'hui car il permet de se rapprocher au plus près du fonctionnement réel d'un micro-processeur tout en faisant abstraction des spécificités à la fois du micro-processeur lui-même et de la plateforme sur laquelle il est installé. Le principal intérêt étant justement d'éviter d'avoir à tout réécrire depuis zéro chaque fois que sort un nouveau produit. D'autant qu'un logiciel est essentiellement une œuvre intellectuelle (donc de la main d'œuvre) représentant généralement des milliers d'années-hommes pour les projets suffisamment conséquents, ce qui dépasse de beaucoup le coût des machines proprement dites (même si elles sont difficiles à mettre au point également).

On a consacré un long fil au même sujet il y a une quinzaine de jours.

ok je vois , mais par exemple il n'y a pas moyen de faire , "si le programme tourne sur x processeur alors faire la commande plus avancé , sinon faire la comande de base qui marche sur tous le processeur de la famille" ??

Sur une même famille, si : cela s'appelle des accélérateurs et ça relève de l'optimisation. Mais il est très rare que la granularité s'affine jusqu'au niveau de l'instruction individuelle car ça triplerait à la fois le volume du code exécutable final et les délais d'exécution, puisque le gain apporté par l'éventuelle instruction optimisée serait annulé par le coût du contrôle, qui serait également payé par la machine ne disposant pas d'instructions optimisées.

Par contre, il arrive assez souvent qu'une routine soit décomposée en deux sous-routines permettant de le faire ou mieux, en deux bibliothèques partagées. On peut alors remplacer une DLL ou *.so par sa version optimisée pour la machine cible de façon complètement transparente.

Toutefois, cela n'a d'intérêt que si l'on s'appuie sur des binaires déjà compilés et qui ne changent pas tous les quatre matins. Dans le logiciel libre, par exemple, il n'y a aucune confidentialité sur le code source et il est généralement disponible automatiquement et en libre accès. Du coup, il est aussi simple de le recompiler directement pour la machine cible et de demander au compilateur d'appliquer globalement un niveau d'optimisation donné. C'est le cas de l'option « -O » (O majuscule) de GCC. Derrière ce paramètre laconique se cache un puissant mécanisme d'optimisation. Avec l'option « -S », tu peux demander au compilateur de te produire le code assembleur correspondant à ce qu'il a compilé plutôt que l'exécutable final. Si tu essaies sur un programme suffisamment conséquent, tu noteras une nette différence entre le code produit par -O0 et -O3.

bah oui mais du coup se fameux chargeur il doit être integrer a l'OS comme il ne peut pas être multi-platforme , il doit être intégré a l'os qui lui est codé pour l'architecture utilisé , sinon sa veut dire que le chargeur est multi platforme et dans se cas le chargeur ne sert a rien , fin c'est comme sa que je vois le truc

« intégré » non. Fourni avec, à la limite. Et c'est normal puisque :

• L'OS n'est pas encore chargé (donc inutilisable) au moment où le chargeur entre en jeu ; (ânerie, voir plus bas)
• Si tous les logiciels avaient besoin d'un OS pour fonctionner, avec quoi fonctionnerait l'OS lui-même ?

Kannagi :

je veux apprendre l'assembleur car j'aime aller au fond des chose , comprendre comment elle fonctionne , puis aussi pour la liberté qu'offre l'asm , pour exploité au maximum le processeur et tout simplement pour le plaisir d'apprendre

C'est exactement l'attitude à avoir !

[jlliagre]

« intégré » non. Fourni avec, à la limite. Et c'est normal puisque :
L'OS n'est pas encore chargé (donc inutilisable) au moment où le chargeur entre en jeu

Je pense qu'il y a confusion ici. Ce à quoi tu fait référence, c'est le boot-loader qui est le chargeur du noyau. J'ai introduit "loader" dans la discussion pour désigner le chargeur dynamique des systèmes d'exploitations, celui qui lit l'en-tête ELF, PE, COFF, a.out, Mach-O, etc. puis prépare l'environnement d'exécution du programme avant d'appeler son point d'entrée.

C'est ld.so / ld.linux.so sous Unix et Linux, il y a bien sûr l'équivalent sous Windows et tous les autres systèmes d'exploitation.

Si tous les logiciels avaient besoin d'un OS pour fonctionner, avec quoi fonctionnerait l'OS lui-même ?

- Tout les logiciels "user-land" ont besoin d'un OS par définition
- Les noyaux ont besoin d'un boot-loader
- Les boot-loaders ont besoin d'un firmware (ex: BIOS, EFI, OpenBoot/OpenFirmware, etc.)
- Seuls les firmwares n'ont pas besoin d'un autre programme préalablement lancé, ils exécutent directement du code stocké en mémoire non-volatile en démarrant à une adresse fixe.

[Obsidian]

Je pense qu'il y a confusion ici. Ce à quoi tu fait référence, c'est le boot-loader qui est le chargeur du noyau. J'ai introduit "loader" dans la discussion pour désigner le chargeur dynamique des systèmes d'exploitations, celui qui lit l'en-tête ELF, PE, COFF, a.out, Mach-O, etc. puis prépare l'environnement d'exécution du programme avant d'appeler son point d'entrée.

En effet, j'ai lu trop vite. C'est corrigé.

- Tout les logiciels "user-land" ont besoin d'un OS par définition
- Les noyaux ont besoin d'un boot-loader
- Les boot-loaders ont besoin d'un firmware (ex: BIOS, EFI, OpenBoot/OpenFirmware, etc.)

Ça, en revanche, ce sont des définitions, sinon fallacieuses, qui sont au moins interprétées abusivement. Cette chaîne est le modèle le plus communément rencontré mais il n'est nullement obligatoire. À l'époque, nombreux étaient les logiciels bootables autonomes, y compris sur PC, qui démarraient directement sur leur disquette sans avoir besoin de système d'exploitation (pas même le DOS). Notamment, celui-ci, même s'il est marqué DOS pour parler de son époque : https://www.youtube.com/watch?v=Qq79lE8sVj4 … ce qui rendait d'ailleurs les utilisateurs perplexes puisque la disquette était illisible avec les outils traditionnels puisqu'elle ne contenait pas de système de fichier. Il fallait la copier secteur par secteur. Aujourd'hui, c'est devenu très difficile d'en trouver. À part des outils tels que memtest86, on n'en trouve pratiquement plus mais pourtant, n'importe qui peut toujours en écrire un et il sera toujours exécuté de la même façon qu'en 1980. Ça commence tout juste à devenir un peu plus compliqué avec UEFI.

Les logiciels « userland » sont, par définition effectivement, des logiciels conçus pour tourner dans un contexte utilisateur. Et si utilisateur il y a, c'est qu'un framework sous-jacent a déjà été défini. Mais si on se réfère au simple mode protégé, et si le logiciel est tout seul sur sa machine, alors il peut invariablement choisir de fonctionner en mode privilégié ou non-privilégié (à sa convenance) et même passer de l'un à l'autre dans les deux sens s'il se prévoit des call gates. Ça n'en fait pas un système d'exploitation pour autant.

- Seuls les firmwares n'ont pas besoin d'un autre programme préalablement lancé, ils exécutent directement du code stocké en mémoire non-volatile en démarrant à une adresse fixe.

La définition exacte d'un firmware, c'est littéralement « le logiciel de la compagnie », c'est-à-dire le soft intégré à un appareil embarqué contenant un micro-processeur et donc nécessaire à son fonctionnement, lequel appareil n'étant pas nécessairement destiné à être utilisé comme un ordinateur. C'est donc un logiciel interne propre à un appareil donné, mais celui-ci n'est pas nécessairement en mémoire non volatile (exemple : les modems ADSL F@st 800 qui avaient besoin d'être chargés par l'ordinateur-hôte), ni à une adresse fixe (le code peut être relogeable et position independant) ni même directement sur support électronique. Rien n'empêche un firmware d'être chargé par un autre firmware, ne serait-ce que pour être remplacé.

En général, toutes les machines démarrent au moins sur un petit logiciel en ROM interne à la machine proprement dite mais même ça, ce n'est pas obligatoire : c'est flagrant avec les ordinateurs à cartouche qui formaient l'intégralité des consoles de jeux jusqu'à l'arrivée de la Playstation, mais également une grande partie de 8 bits : les Thomson (qui étaient réputés pour cela), mais également le 6128+ avec le Basic et Burnin' Rubber dans une cartouche amovible. En temps normal, à la mise sous tension, l'ordinateur ou la console concernée démarre sur sa ROM interne, fais les initialisations nécessaires puis embraye sur le logiciel de la cartouche, mais ce n'est même pas obligatoire : la cartouche (qui embarquait généralement une simple EPROM) peut très bien prendre place à une extrémité du plan mémoire et donc être la première chose qui soit interprétée par le micro-processeur.

Tout cela est important car, parfois, ce n'est pas clair dans l'esprit des utilisateurs. Du temps de Windows 95, un ami qui avait acheté son premier PC et dont je critiquais le système m'avait tenu à peu près ces propos :

— Mais moi, j'ai toujours entendu dire que les bugs se produisaient au niveau logiciel, Or Windows est un OS ;
— Et un OS, ce n'est pas un logiciel ?
— Je ne sais pas si OS = logiciel…

Dans tous les corps de métier, donc, on a avoir affaire à des personnes normalement intelligentes mais pour qui certaines notions qui nous paraissent complètement implicites ne le sont pas forcément.

[jlliagre]

Il y a toujours au démarrage initial d'un équipement informatique contenant un microprocesseur un firmware qui exécute un code présent en mémoire persistante ((EP)ROM) démarrant à une adresse fixe, c'est un prérequis des microprocesseurs.

En général, ce code va effectuer un certain nombre de tests puis ensuite, bien sûr, c'est "open". Rien n'interdit comme tu le soulignes de modifier ce modèle. On peut enchaîner des firmwares successifs, enchaîners les boot loaders, empiler les OS avec de la virtualisation, remplacer ou court-circuiter certaines couches comme sur l'Atari ST qui est dans mon grenier où le système démarre immédiatement au boot car l'OS est stocké en EPROM. Pas de boot-loader, le firmware et le système d'exploitation ne font qu'un.

J'ai décris dans mon post précédent le modèle d’enchaînement standard que l'on rencontre avec les systèmes d'exploitation usuels et sur les ordinateurs modernes et je me suis limité à l'acception "logiciel applicatif". Il est clair que des programmes, il y en a à tous le niveaux.