plop,
 
j'ai programmer plusieur micro controlleur en assembleur et chaque µ a un language different ne serait-ce deja du a leur architecture differente (pas les meme port, pas le meme nombre d'accumulateur ou de registre)
je me posais donc la question, quand je devellope un programme en C sur windows, ce programme marchera sur tous les ordinateur quelque soit leur processeur.
comment est-ce possible? mon .exe embarque les fichier assembleur codé pour chaque processeur existant?
 
thanks

Non ton exe marchera pas sur toutes les plateformes, il te faut recompiler ton code pour chaque type de plateforme.

parceque c'est le compilateur qui justement fait l'abstraction du matériel : toi t'écrit en langage relativement presque humain "while (true) if (dosomething()) break;"
 
et c'est le compilateur, qui en fonction du target choisi, va générer le code assembleur dédié au processeur destination.
 
et puis aussi, même les machintosh on aujourd'hui les instructions ASM de l'architecture 8086. donc d'un PC à l'autre, il y a un tronc commun qui permet déjà de tout faire. les particulatirités entre un AMD64 ou un Core2 Duo d'Intel, c'est que des sets d'instructions en plus, donc on peut parfaitement se passer (elles n'ont pour seul intérêt que d'être plus optimisées que celles de bases, sous forme de macro instructions)
 
Donc d'un CPU "intel compatible" à l'autre, y'a pas trop de question à se poser.
 
Et ensuite, oui, on peut avoir des EXE qui contiennent plusieurs fois le même morceau de code, mais optimisé pour différents processeurs. le compilateur ajoute alors les tests nécessaires pour choisir en fonction du processeur détecté quel partie du code exécuter.
 
M'enfin je laisse harko t'en dire plus, il ne communique qu'en ASM
 
Par contre, comme le souligne Alload, il y a la couche OS qui par contre est problématique. Sur un PC, c'est l'OS qui met à disposition du programme les interruptions notamment, la mémoire et autres. Donc si ton programme n'est pas compatible avec l'OS, ça ne marchera pas.
 
Et là, à part faire du "JITC" (just-in-time-compilation) -Java* ou .NET par exemple- qui va effectuer la compilation finale du programme au moment où on le démarre, y'a pas de solution.
 
* (enfin, java c'est l'ancêtre du JITC, c'est encore autrechose qui s'apparente plus à de l'interprétation)

Ouais enfin il y a autre chose que le x86 dans le monde, les macs ne sont peut-être plus sur PPC mais les PPC existent encore, de même que les Sparc (parce que les serveurs très haut niveau ultracores de Sun c'est pas du x86 dedans, c'est du SPARC/Niagara)

donc en fait, les processeur pour ordinateur sont relativement semblabe afin que le code ecrit puissent fonctionner sur la plupart d'entre eux.
il on tous un jeu d'accus, registre, d'intruction de base.
puis ils en on en plus qu'on peut utiliser pour rendre un programme plus performent mais qui ne marchera que sur une certaine famille de processeur
 
alors qu'en electronique chaque fammille de µC, constructeur a un jeu d'instruction totalement differente et aussi une architechture differente

non. Magicbuzz raconte n'importe quoi et ne parle que de l'archi la plus populaire et fréquente sur PC de bureaux, x86 (qui est une archi existant et évoluant depuis 30 ans puisqu'elle est née avec le 8086 en 1978).

donc un programme embarque plusieur version assembleur du programme? une pour chaque architecture

mais non
relis la réponse d'alload au début : un programme est compilé pour une architecture précise. si tu veux qu'un programme x86 tourne sur PPC par exemple, alors il faut le recompiler avec un compilateur qui génerera de l'assembleur PPC, etc...
j'ai la nette impression que tu confonds exécutable et source

il parle de PC, pas de serveurs sun que je sâche...
 
-- edit : a, quoique non en fait, c'est moi qui ai fait le raccourci, désolé

Un petit peu d'histoire :
http://en.wikipedia.org/wiki/IBM_PC_compatible

 
plus façile de se moquer que d'expliquer.
 
chaque famille de micro-controlleur a un language different, un programme ecrit pour une famille ne marchera pas sur l'autre.
or un programme ecrit sur windows fonctionnera sur windows quelque soit le processeur utilisé, pourquoi?

Il ne fonctionnera que si il n'utilise que des instructions communes aux différents processeurs

La première réponse du topic t'a donné l'info nécessaire, le reste est sur la wikipédia.

C'est pas du tout le cas.

 
Et j'ajouterais que si l'on compte l'embarqué en sus, on n'a pas fini de lister les architectures différentes...

mais ça va pas non ?
le seul cas dans lequel ton affirmation est vraie, c'est dans le cas de programmes écrits en Java, Python, .NET ou tout autre langage se reposant sur une virtual machine. Alors là oui, effectivement, quel que soit le processeur ciblé, ton programme tournera -normalement- sur un autre processeur sans recompilation à condition que la machine virtuelle soit présente sur la machine cible.

mais faire tourner un programme compilé pour un processeur sur un autre processeur, même s'ils utilisent le même OS, c'est impossible

Oué mais il parlait d'ordinateur, alors je me suis restreint à ça, et j'ai même pas parlé des "big irons" (z/Architecture, PA-RISC) ou des trucs morts (Alpha, VAX, Itanium)

Ou alors via couches d'émulation qui peuvent se lancer de manière transparente (e.g. Rosetta sur Mac pour faire tourner des logiciels OSX/PPC sur un Intel Mac).

D'ailleurs, il y a strictement le même problème si on inverse (même archi CPU, OS différent)

 
Pour expliquer un peu plus en détail pourquoi c'est possible à notre ami : c'est tout simplement parce qu'il y a une virtual machine différente, et spécifique, à chaque architecture. Donc le bytecode java ou .net ou autre tourne sur une "virtual machine" commune à toutes les architectures, mais tu seras dans l'impossibilité d'exécuter ton programme si ta plateforme n'a pas de virtual machine prévue existante dessus.
 
Donc en gros, ça déplace le problème, le seul (très gros) avantage c'est qu'un développeur ne compile effectivement qu'une fois son programme et que ça tournera partout... pour peu qu'une VM existe sur la plateforme cible.

Java, code one, crash everywhere

ouais, enfin quand je parlais des instructions x86, aujourd'hui tout processeur "intel compatible" qui a moins de 5 ans on va dire, supporte les instructions i386, i486, pentium, MMX, SSE, SSE2 et 3DNow!
 
ensuite, comme je le disais, j'en suis quasi sûr et certain, certains compilateur génèrent au sein du même exe des morceaux redondants, plus ou moins adaptés à différentes architectures. ainsi si la machine n'a pas 3DNow, c'est la partie SSE qui sera exécutée, et vice-versa.
 
tu prends Visual C++ version 2008. Tu compiles. C'est du C++, y'a pas de byte-code ou autre JITC, et pourtant ça marche aussi bien sur un processeur Intel qu'AMD à partir du moment où le processeur est supporté par Windows 98 (si je ne m'abuse, c'est la limite de backward compatibility pour VS2008)
 
la plupart des programmes qu'on trouve, c'est compilé "win32", et ça tourne aussi bien sur AMD qu'Intel, que ce soit en 32 ou 64 bits (à l'exception des intels 64 bits tout pourris pour les serveurs, qui savent pas faire du 32 bits et que Microsoft à de toute façon lâché dès le départ)
 
J'ai encore jamais vu en rayon à la fnac une version AMD d'un jeu et à côté une version Intel du même jeu, qui sont pourtant certainement le type le programme le plus optimisé possible.
 
Par contre faire tourner un programme affichant un superbe slide "3DNow optimised" sur un Pentium MMX à l'époque, aucun souci : le code générique est présent aussi dans le binaire, et si il ne trouve pas les instructions 3DNow, il switch sur la partie générique, moins optimisée mais qui marche tout aussi bien.
 
Et ça, pour moi c'est une bête option dans le compilateur.

MagicBuzzG
Mais c'est normal que ça marche, ce sont des processeurs identiques, avec le même jeu d'instructions

MagicBuzzG        

Tu sais pas de quoi tu parles, tu racontes n'importe quoi et tu réponds à côté, retournes dans la cat sql stp

Et accessoirement

C'est ptet parce que les processeurs "64 bits" dont tu parles sont des hybrites 32/64 et sont toujours des x86 (hint: la techno s'appellait x86-64 à sa sortie)

L'itanium lui était une tentative de repartir sur des bases propres avec une archi clean et 64 bits, donc il risquait pas de gérer le 32 bits

T'ira voir si un Athlon et un P2 c'est le même jeu d'instruction.
Y'en a un qui a 3DNow et pas SSE, alors que l'autre c'est l'inverse.
Le plus grand dénominateur commun, c'est MMX entre ces deux processeurs...
 
Donc non, y'a une base commune (et c'est l'objet de ma première réponse), mais c'est pas 100% commun.
 
Et pourtant rien n'empêche un programme, avec le même EXE, d'utiliser 3DNow ou SSE selon lequel est présent sur le processeur, ou aucun des deux si aucun n'est trouvé. Soit c'est le compilateur qui fait ça comme un grand, soit c'est le dev qui a rajouté des portions optimisées à la main

 

 
La base commune, c'est l'architecture x86
 

 
Jeu d'instruction additionnel != architecture.

c'est fini de jouer sur les mots ?
 
tout à l'heure je parle d'architecture x86, et on me sort que ça date de 1971 que c'est d'la merde que c'est n'importe quoi.
 
et maintenant c'est toi qui en parle.
 
alors faudrait savoir.

Non, relis bien les messages de Masklinn. Il te reproche justement de ne parler que des architectures x86 qui sont les plus répandues dans le grand public, que ça a 30 ans etc.

effectivement, mal lu, désolé. et effectivement, j'avais cru lire "PC" dans le post original, et j'étais donc parti des architectures PC qui sont toutes à base de x86, puisque même les mac supportent aujourd'hui les jeux d'instruction x86

bon on se fait tous des bisous, et on dit à sliders_alpha qu'un programme compilé sur un processeur ne marchera pas sur un autre processeur sans recompilation, et pis c'est tout

*il ne marchera pas sur un processeur d'architecture différente

 
Pour faire un parallèle avec les micro-controleur, on peut dire que tous les processeurs x86 sont de la même famille, donc ils ont le même langage assembleur (ils ont un tronc commun en tout cas)