B'jour!

Alors, on code nôtre affaire, on le fais compiler, et il devient code binaire.

Mais, m'semble que l'on m'a souvent dit que chaque machine(sauf les identiques...) avaient leurs code propre à elle. (heu... un truc comme ça :p)
Donc, je me demandais comment le compilateur faisait pour faire un code compatible à toutes les machines.
Un algorithme impossible qui prévoit tous les cas?
Une norme que l'on apprend au processeur quand il arrive à un code?
J'ai juste rien compris?

heu...

Il me semble que le compilateur compile passe par l'assembleur, un langage de très très bas niveau mais qui marche sur tous les processeurs qui ont été prévu pour.

En général on a donc différents types de portabilité, entre autres :
- l'assembleur produit : on est obligé de compiler pour x86 (la majorité des Intel/AMD connus), pour x86_64 (pour l'AMD_64, mais ce n'est pas incompatible avec x86, c'est juste l'optimisation qui est différente), pour powerpc (les Macintosh), et d'autres architectures (processeurs) moins connues
- les commandes/librairies utilisées : certains librairies n'existent pas partout, même au sein de machines ayant le même type de processeur. Par exemple un programme utilisant les librairies Win32 pour sa partie graphique ne tournera pas bien sous unix/linux. Plus simple encore, si tu mets un system("PAUSE"); dans ton code, tu peux être sur que ca va poser problème à tous les gens qui ne sont pas sous windows.

Pour avoir une plus grande indépendance vis-à-vis de la machine, certains langages proposent (ou imposent) de passer par une machine virtuelle. Le code est alors écrit pour un processeur qui n'existe pas, mais qui est universellement reconnu.

Lors de l'exécution du programme, il est nécessaire de lire cette écriture universelle (qu'on appelle bytecode) pour la retranscrire vers un langage que le processeur peut effectivement lire. Cela a l'inconvéniant que le code n'est plus compilé mais interprété, d'où une baisse de la vitesse d'exécution.

Les versions récentes de ces langages s'efforcent évidemment de palier le problème de la vitesse, par différentes techniques.

Ou alors, comme l'a dit bluestorm, on se base sur des instructions communes à toute une gamme de processeur, mais alors on perd les optimisations dûes aux spécificités de chacun des processeurs.

Bien évidemment, quand on fait du logiciel libre le problème de la compatibilité architecturale se pose moins : n'importe quel gugusse peut compiler le code pour sa plate-forme s'il le souhaite.

ben

Citation : bluestorm

n'importe quel gugusse

je suis pas d'accord.
c'est chaud de compiler un logiciel un peu compliqué
et puis le blem des librairies se pose quand même (sauf si on utilise wine pour win -> linux)

Citation : Navaati

c'est chaud de compiler un logiciel un peu compliqué

En effet, c'est chaud . Pour les librairies, c'est normalement fourni avec de telle façon que ce ne soit pas un problème pour l'utilisateur. Et si on doit passer par Wine, c'est généralement que le programme n'est pas libre. Il suffit d'avoir les sources pour compiler, et les logiciels libres nous garantissent d'avoir les sources.

Normalement il n'y a rien de compliqué dans la compilation sauf si tu essaies de compiler par ex un système avec la glibc et ce genre de conneries, il peut y avoir des soucis, faut trouver des patchs qui trainent etc. et ton système peut être instable ou ne pas marcher tout court mais bon, sinon, un bête prog, c'est simple.