Discussion :

[Preez]

Bonsoir à tout(te)s.
Dans le Chapitre 1 des cours de C d'Anne Canteaut, sont spécifiés les 4 étapes du processus de compilation d'un programme de type C. Je voulais savoir pour quelles raisons les informations contenu dans le fichier source ne sont pas directement converties en base 2? Pourquoi doit on passer le fichier source en assembleur? Même si l'assembleur est un language plus proche de la machine que le C, l'on est capable d'obtenir le code binaire d'une information codée en base décimale, pourquoi dans ce cas le compilateur ne se contente pas d'assurer la conversion base(10) -> base(2)?
Merci de m'éclairer sur ce point, dans la mesure du possible.

[Emmanuel Delahaye]

Dans le Chapitre 1 des cours de C d'Anne Canteaut, sont spécifiés les 4 étapes du processus de compilation d'un programme de type C. Je voulais savoir pour quelles raisons les informations contenu dans le fichier source ne sont pas directement converties en base 2? Pourquoi doit on passer le fichier source en assembleur? Même si l'assembleur est un language plus proche de la machine que le C, l'on est capable d'obtenir le code binaire d'une information codée en base décimale, pourquoi dans ce cas le compilateur ne se contente pas d'assurer la conversion base(10) -> base(2)?
Merci de m'éclairer sur ce point, dans la mesure du possible.

Ben en fait, ça dépend du compilateur. Il faut savoir que pendant longtemps, et pour ne pas réinventer la roue, on considérait comme plus simple de demander au compilateur de générer le code en langage assembleur, celui-ci étant ensuite traité par un outil bien connu et bien rodé pour générer du code machine qui est "l'assembleur" (as dans le monde unixoïde).

D'autres compilateurs (Borland, gcc ?...) court-circuitent cette phase et génèrent le binaire directement. Ca na pas beaucoup d'importance. Il faut savoir qu'en général, il est possible avec une option (gcc : -S) de générer et de conserver le code source en assembleur (commenté avec le source C), ce qui peut aider au débuggage de bas niveau, notament quand on utilise un débogueur matériel ou un émulateur (ICE).

Ca peut aussi avoir un intérêt pédagogique si l'optimisation n'est pas trop poussée (sinon le code et trop éloigné du C, et on ne voit pas la relation entre le C et le code en assembleur)

[Jean-Marc.Bourguet]

Ben en fait, ça dépend du compilateur. Il faut savoir que pendant longtemps, et pour ne pas réinventer la roue, on considérait comme plus simple de demander au compilateur de générer le code en langage assembleur, celui-ci étant ensuite traité par un outil bien connu et bien rodé pour générer du code machine qui est "l'assembleur" (as dans le monde unixoïde).

C'est aussi plus facile de débugger le compilateur quand il sort de l'assembleur. Et une raison supplémentaire, c'est que quand on fonctionne avec 64K de mémoire (comme le PDP-11 sur lequel C a été conçu), on est obligé de faire des choses pour que le programme tienne en mémoire. Soit plusieurs passes avec des exécutables séparés (préprocesseur, front-end, optimiseur, génération de code, assembleur, ... je me souviens avoir lu quelque part qu'un des premiers compilateurs Fortran avec une quarantaine de passe comme ça; les premières machines avaient encore moins de mémoire), soit de jouer avec des overlays (de nos jours on utiliserait des bibliothèques dynamiques qu'on chargerait explicitement et qu'on déchargerait quand on n'en a plus besoin).

[Preez]

D'accord, merci à vous deux, encore une fois, pour vos réponses.
Avec les ordinateurs actuels et leurs mémoires de plus en plus importantes, je n'ai donc pas à me soucier de cette partie de la compilation pour mon apprentissage du C?

ce qui peut aider au débuggage de bas niveau

On est donc parfois obligé de débugger en assembleur? Ca commence à me faire peur, un language peut en cacher un autre !
Plus sérieusement, après vos réponses, j'estime que je n'ai pas trop besoin de m'occuper de ça, je poursuis donc ma route!
merci!

[Emmanuel Delahaye]

Avec les ordinateurs actuels et leurs mémoires de plus en plus importantes, je n'ai donc pas à me soucier de cette partie de la compilation pour mon apprentissage du C?

C'est ça.

On est donc parfois obligé de débugger en assembleur ? Ca commence à me faire peur, un language peut en cacher un autre !

Grr... Langage...

Pas dans les applications courantes. Parfois, ça peut aider dans des processus d'optimisation fines, pour voir l'impact de tel ou tel codage en C ou reglage d'optimisation du compilateur sur le code créé. C'est plutôt rare...

Plus sérieusement, après vos réponses, j'estime que je n'ai pas trop besoin de m'occuper de ça

Exactement.

[Preez]

D'accord, merci!
Une dernière petite question, en revanche! Je ne savais pas ce qu'était des "overlays", j'ai donc recherché un peu, et, si j'ai bien compris ce sont des informations stockées ( et consultées) sur la mémoire de masse, pour économiser la mémoire vive (le site précise que les DLL de Windows sont des overlays). Je voulais donc savoir pourquoi dis-tu "de nos jours on utiliserait des bibliothèques dynamiques.." Jean-Marc? Cette "technique" est reservée aux "gros" programmes, enfin à ceux qui consomment pas mal de mémoire vive? Et pour finir, est-ce que ça fait partie des "bases" du C cette affaire?

N.B: Emmanuel, j'ai suivi les liens de ton site, et j'apprends effectivement beaucoup de choses, mais ça demande nettement plus de temps et de travail que les scanf() toutes les deux lignes... Et puis faut toujours faire des tests, pour vérifier les entrées ("se méfier de l'utilisateur, l'utilisateur est nuisible" ) ou la mémoire, enfin c'est vraiment autre chose!

[Jean-Marc.Bourguet]

Une dernière petite question, en revanche! Je ne savais pas ce qu'était des "overlays", j'ai donc recherché un peu, et, si j'ai bien compris ce sont des informations stockées ( et consultées) sur la mémoire de masse, pour économiser la mémoire vive (le site précise que les DLL de Windows sont des overlays). Je voulais donc savoir pourquoi dis-tu "de nos jours on utiliserait des bibliothèques dynamiques.." Jean-Marc? Cette "technique" est reservée aux "gros" programmes, enfin à ceux qui consomment pas mal de mémoire vive?

Je ne suis pas d'accord: les DLL de Windows permettent d'implémenter des overlays, mais sont un mécanisme plus général et principalement utilisé avec un autre objectif.

Ce qui a fait qu'on n'emploie plus cette technique, c'est la mémoire virtuelle qui permet, entre autres, de ne plus avoir une correspondance stricte entre espace d'adressage utilisable et mémoire installée.

Les overlays c'est une technique utilisée quand on a un espace d'adressage utilisable plus petit que l'espace nécessaire pour le programme.

[InOCamlWeTrust]

Je voulais savoir pour quelles raisons les informations contenu dans le fichier source ne sont pas directement converties en base 2?

La base deux n'a rien à voir avec la compilation : on pourrait très bien imaginer des processeurs travaillant dans une autre base et conserver les codes source C (IBM avait tenté la base trois, de mémoire)... d'ailleurs, ton code source est déjà en base deux !

Pourquoi doit on passer le fichier source en assembleur? Même si l'assembleur est un language plus proche de la machine que le C, l'on est capable d'obtenir le code binaire d'une information codée en base décimale, pourquoi dans ce cas le compilateur ne se contente pas d'assurer la conversion base(10) -> base(2)?
Merci de m'éclairer sur ce point, dans la mesure du possible.

Tu mélanges les pinceaux, là ! Tout est binaire dans un ordinateur actuel : le noyau, ton code, l'exécutable, et même les photos porno que l'on peut récupérer à droite et à gauche !

Le fait que tel suite d'octets est un code source ou un exécutable dépend de l'interprétation que l'on veut faire de la suite de bits du fichier.

C'est ainsi que l'on cachait des informations dans les exécutables, sur certains processeurs, dont le 68K : certaines suites de bits soit ne correspondaient pas à une instruction machine, soit étaient correspondaient à des instructions non définies dont certains champ pouvaient contenir ce que l'on voulait, et entre autres des chaînes de caractères. C'était parmis les premières méthodes d'authentification.

Cependant, tu peux faire le test suivant : prend un exécutable (n'importe lequel, en général) et ouvre-le grâce à un éditeur héxadécimal. Tu verras alors que certaines informations te paraîtront lisibles.

Pour gcc, si on ne précise rien, il utilise des fichiers temporaires, à moins qu'il aie été compilé avec les options qu'il faut, auquel cas il utilise des pipes (mais pourquoi les programmes utilisent-ils encore cette technologie ancestrale, alors que l'on a des sockets anonymes, locaux, etc... ?)

[Preez]

d'ailleurs, ton code source est déjà en base deux !

Comment mon code source peut-il être en base(2)? Il contient autre chose que des "0011010010110110", il est donc en base décimale, non? Là je suis perdu, lorsque tu dit :

Tout est binaire dans un ordinateur actuel

je le comprends bien, mais il y a quand même des conversions, par exemple sur le flux "de sortie visuelle, avec l'écran" (désolé, j'arrive pas encore à m'exprimer compréhensivement sur ces points là), il est obligatoire de convertir ces données binaires en images, textes, courbes vectorielles et tout le toutim pour interragir avec l'utilisateur. Ma question de départ ne portait donc pas sur la nature des informations, mais sur le chemin utilisé pour que les instructions/informations contenues dans mon programme de départ soient comprises par l'ordinateur, donc en données binaires.
Il me manque certaines notions pour définir clairement ce qui se passe sur les différents flux et les types de données qui y transitent.
Je cherche de mon côté, si vous avez des liens, je suis preneur!
Merci à vous!

N.B: InOCamlWeTrust, faut encore que je cherche ce que sont des pipes, et bah dis-donc, sacrée journée...

[koala01]

Salut,

Comment mon code source peut-il être en base(2)? Il contient autre chose que des "0011010010110110", il est donc en base décimale, non? (snip)

Hé non... l'ordinateur ne peut gérer que deux états: le courent passe ou il ne passe pas...

C'est une loi du "tout ou rien". Il n'y a donc pas d'état intermédiaire entre le 1 (le courent passe) et le 0 (le courent ne passe pas)

Ce qui se passe, c'est que l'ordinateur dispose d'une série de tables qui permettent de faire la correspondance entre le fait que le caractère de valeur 00100000 en binaire (32 en décimal) correspond à un espace

Au mieux, en groupant les différents bits entre eux par 4 ou ses multiples on peut obtenir une notation exadécimale (de base 16), c'est à dire avec des valeurs allant de 0 à F, qui ne sera qu'une représentation plus facilement utilisable pour nous (car moins longue à écrire qu'en binaire)

C'est la raison qui fait, entre autre, qu'un ko correspond à 1024 octets,qu'un mo correspond à 1024 ko et qu'un go correspond à 1024 mo (1024 étant la valeur composée d'un seul 1 dans un ensemble de bits la plus proche de 1000)

Quand, dans un programme tu écrit

Code :

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

int i=10;

i correspond à une adresse de taille suffisante pour gérer un entier (*souvent* 32 bits) et prend en fait une valeur binaire correspondant à 10 (00000000 00000000 00000000 00001010)

je le comprends bien, mais il y a quand même des conversions, par exemple sur le flux "de sortie visuelle, avec l'écran" (désolé, j'arrive pas encore à m'exprimer compréhensivement sur ces points là), il est obligatoire de convertir ces données binaires en images, textes, courbes vectorielles et tout le toutim pour interragir avec l'utilisateur.

Pour l'affichage d'une photo, d'un texte ou de n'importe quoi à l'écran, le système se "contente", apres traitement, d'envoyer une série de bit à une adresse mémoire qui est prévue pour afficher quelque chose à l'écran

Et c'est le codage de l'application qui fournira la manière dont le système doit réagir à telle ou telle entrée (que ce soit le clavier, la souris, ou un fichier récupéré sur l'ordinateur) en déplacant/copiant/modifiant les données qui se trouve dans la mémoire destinée à l'affichage.

Il faut bien te dire que, à la base, un ordinateur c'est ce qu'il y a de plus bete...

Il ne sait, en gros que faire quelque actions simples sur les données (qui sont d'office au format binaire, vu que c'est la seule chose qu'il sache faire )

Une liste,peut etre pas tout à fait complete, en fonction de l'évolution du processeur, de ce qu'il sait faire serait

• copier le contenu d'une adresse mémoire vers une autre adresse memoire ou un autre endroit ("stack" ou "Accu")
• enregistrer une valeur dans une adresse mémoire
• additionner deux valeurs
• inverser les bits (0 devient 1 et 1 devient 0) (on parle de "complement à 1")
• grace aux deux précédents: soustraire une valeur à une autre (mais il doit encore rajouter 1 pour que cela reste cohérent)
• comparer deux valeurs
• interpréter certaines valeurs comme étant des instructions (mais, s'il tombe sur une valeur qui ne correspond à aucune instruction, il ne sait pas quoi faire)

Par extension, il arrive à faire d'autres choses, comme multiplier (2*3 est pareil que 2+2+2 ), diviser (compter le nombre de fois qu'il soustrait une valeur d'une autre), mais, à la base, c'est à peu pres tout ce qu'il sait faire sur les valeurs

[InOCamlWeTrust]

Comment mon code source peut-il être en base(2)? Il contient autre chose que des "0011010010110110", il est donc en base décimale, non? Là je suis perdu, lorsque tu dit :
je le comprends bien, mais il y a quand même des conversions, par exemple sur le flux "de sortie visuelle, avec l'écran" (désolé, j'arrive pas encore à m'exprimer compréhensivement sur ces points là), il est obligatoire de convertir ces données binaires en images, textes, courbes vectorielles et tout le toutim pour interragir avec l'utilisateur. Ma question de départ ne portait donc pas sur la nature des informations, mais sur le chemin utilisé pour que les instructions/informations contenues dans mon programme de départ soient comprises par l'ordinateur, donc en données binaires.
Il me manque certaines notions pour définir clairement ce qui se passe sur les différents flux et les types de données qui y transitent.
Je cherche de mon côté, si vous avez des liens, je suis preneur!
Merci à vous!

N.B: InOCamlWeTrust, faut encore que je cherche ce que sont des pipes, et bah dis-donc, sacrée journée...

Ne confonds pas tout ! Ce n'est pas parce que tu vois des nombres décimaux à l'écran que ton code est écrit en décimal.

Un carcatère de ton code correspond à un numéro de caractère (ASCII, normalement) : donc ton code est totalement composé de nombres représentés en machine en base 2. Les espaces, les tabulations, les retours à la ligne, les chiffres et même la cloche système sont des caractères, c'est-à-dire des numéros.

Lorsque tu ouvres ton éditeur de texte préféré, ton éditeur ouvre le fichier contenant ton code source. L'éditeur ne voit que des nombres, les nombres des codes ASCII dans ce cas. Il possède ensuite une interface avec un "serveur graphique" et un ensemble de polices, qui sont des ensembles de dessins (les dessins des lettres) pouvant être stockés sous forme de fichier (lui aussi binaire...), mais pas exclusivement.

Fondamentalement, et pour faire très simple, pour afficher un caractère, les grandes étapes pourraient être résumées comme suit :

1- lorsque l'éditeur lit un caractère (son code ASCII en réalité), il cherche le dessin correspondant à cette lettre

2- une fois le dessin de lettre trouvé, il demande au serveur graphique de l'afficher à l'écran. Là encore, l'affichage est purement binaire, étant donné que chaque pixel est un couple position-horizontale / position-verticale... donc des nombres (en base 2)

3- pour la ligne de commande, c'est exactement pareil, étant donné que le programme que tu lances quand tu veux afficher le terminal est lui aussi... graphique.

Quand je dis "l'éditeur" ou le "serveur", ce sont deux notions très vagues, car il existe en fait beaucoup de couches au niveau graphique.

Sous Linux, le serveur X (instrallé en local, hein, pas d'internet ici !) permet d'afficher des choses très rudimentaires dans un espace donné.

Le serveur Xt (je ne me souviens plus exactement du nom, mais je pense que ça doit être ça) est au-dessus de X et se sert de X pour fournir des services plus avancés.

Enfin, les interfaces avancées comme Gnome ou KDE utilisent Xt, principalement.

Il y a aussi le driver, construit en-dessous de X qui permet de communiquer avec le matériel.

[Preez]

Ouch!!! Merci à vous deux pour toutes ces infos, je m'y retrouve mieux à présent. Donc au final, tout est en binaire (note: faire confiance à InOCamlWeTrust du premier coup, la prochaine fois ). Et, par déduction , sur Linux, on peut voir toutes les instructions permettant de faire tout ça (chercher le dessin correspondant au code ASCII, affichage de celui-ci) dans le code source???? Il y a quand même quelques points qui restent obscurs (en quoi est codé un OS? Si ce n'est pas en binaire, il doit donc y a voir dans cet OS des fonctions permettant de comprendre le langage dont se sont servi les programmeurs etc..), mais je comprends que tout part d'une loi du "tout ou rien".
Encore merci à vous deux!

[Emmanuel Delahaye]

Et, par déduction , sur Linux, on peut voir toutes les instructions permettant de faire tout ça (chercher le dessin correspondant au code ASCII, affichage de celui-ci)

Ca s'appelle le glyphe.

dans le code source????

Tu le trouveras plutôt dans la PROM de ta carte graphique...

Il y a quand même quelques points qui restent obscurs (en quoi est codé un OS? Si ce n'est pas en binaire, il doit donc y a voir dans cet OS des fonctions permettant de comprendre le langage dont se sont servi les programmeurs etc..), mais je comprends que tout part d'une loi du "tout ou rien".

J'ai un peu du mal à comprendre tes interrogations. L'OS est un logiciel comme un autre. Il a donc été écrit dans un langage quelconque (Assembleur, C ...), puis traduit en langage machine, c'est à dire en une successions de 0 et de 1 généralement groupés en blocs de 8, 16 ou 32 bits (ou autres) selon les machines.

[Preez]

Non c'était juste ce que je voulais savoir, si il était en C, Assembleur etc. Mais donc, sous Windows, on ne pourra jamais voir les sources? Elles sont pourtant bien là, quelquepart... Si ce n'est pas possible, avez-vous des liens pour télécharger des sources d'OS à la UNIX, ou autres, pour me rendre compte de ce que c'est...
Merci Emmanuel pour tes précisions.

[Jean-Marc.Bourguet]

Non c'était juste ce que je voulais savoir, si il était en C, Assembleur etc. Mais donc, sous Windows, on ne pourra jamais voir les sources? Elles sont pourtant bien là, quelquepart...

Une fois un programme converti en langage machine, il n'y a pas besoin des sources. Seuls les langages interprétés ont besoin des sources à l'exécution, et encore pas mal d'entre eux ont des formes plus ou moins compilées.

Si ce n'est pas possible, avez-vous des liens pour télécharger des sources d'OS à la UNIX, ou autres, pour me rendre compte de ce que c'est...
Merci Emmanuel pour tes précisions.

http://www.kernel.org/pub/linux/kernel/

je te conseille de regarder des vieilles versions plutôt que les récentes. Il y a aussi le bouquin de Tanenbaum
http://vig.prenhall.com/catalog/acad...429388,00.html

Mais j'ai l'impression qu'il y a encore beaucoup de confusion dans ton esprit et je ne suis pas sûr qu'aller voir cela ne l'augmentera pas.

[Emmanuel Delahaye]

Non c'était juste ce que je voulais savoir, si il était en C, Assembleur etc. Mais donc, sous Windows, on ne pourra jamais voir les sources?

Non. C'est propriétaire. (Bill Gates, tu connais ?)

Elles sont pourtant bien là, quelquepart...

Ben oui, sur le portable de Bill Gates.

Si ce n'est pas possible, avez-vous des liens pour télécharger des sources d'OS à la UNIX, ou autres, pour me rendre compte de ce que c'est...

Les sources du noyau de GNU/Linux sont libres. Ce sont des millions de lignes de code source écrites en GNUC (une variante non standard du C) et de l'assembleur qui dépend de la cible...

Je ne vois pas bien ce que ça va t'apporter à part te faire peur, mais si tu y tiens :

http://www.kernel.org/

[InOCamlWeTrust]

Ce sont des millions de lignes de code source écrites en GNUC (une variante non standard du C) et de l'assembleur qui dépend de la cible...

Juste au passage.

J'ai compté l'autre jour le nombre de lignes de code d'un noyau 2.4.* : environ 4 milions et demi. Par contre, je n'ai vu aucune ligne d'assembleur, et j'ai pourtant cherché. Je pense qu'il doit bien y en avoir, mais je n'en ai pas trouvé. Par contre, le fait que les Linux modernes soient entièrement écrits en C de A à Z ne m'étonnerait pas plus que ça.

Pour ce qui est de l'implantation version gcc du C, je ne dirai qu'une chose : c'est la mieux pensée (à mon avis). Dommage qu'il faille faire du code portable, car dans le cas contraire, je coderais bien plus souvent en C gcc !

[Emmanuel Delahaye]

J'ai compté l'autre jour le nombre de lignes de code d'un noyau 2.4.* : environ 4 milions et demi. Par contre, je n'ai vu aucune ligne d'assembleur, et j'ai pourtant cherché. Je pense qu'il doit bien y en avoir, mais je n'en ai pas trouvé. Par contre, le fait que les Linux modernes soient entièrement écrits en C de A à Z ne m'étonnerait pas plus que ça.

Il faut que tu prennes une implémentation du noyau pour une cible donnée. Le noyau commun (2.4, 2.6) est en GNUC, mais il n'est pas complet.

Et je compte dans 'assembleur', les parties de sources en GNUC contenant de l'assembleur 'inline' (à ce magnifique format AT&T).

[Jean-Marc.Bourguet]

Par contre, je n'ai vu aucune ligne d'assembleur, et j'ai pourtant cherché. Je pense qu'il doit bien y en avoir, mais je n'en ai pas trouvé.

Il y en a peu, mais il y en a. De mémoire, dans le répertoire arch, cherche les fichiers .S. En plus, il y a aussi un peu d'assembleur inline dans le code C.

[koala01]

Il faut bien comprendre que, meme en dehors de l'informatique, on est tous les jours confrontés à trois gros types de langages (en simplifiant un peu)

D'abord, tu as le langage "humain": nos mots ont une orthographe précise, ont au moins un sens bien précis, meme si certains mots en ont plusieurs, on tourne nos phrases selon une grammaire bien déterminée... mais... notre intelligence nous permet de comprendre un texte meme s'il y a des fautes d'orthographe, d'interpréter ce qui est dit ou écrit en fonction du contexte, à l'aide de la ponctuation ou de l'intonnation de voix, et ce, meme si, dans un contexte donné, le message que l'on fait passer dit exactement l'inverse de ce que le texte semble indiquer (question: Savez vous comment on dit "oui" en Brusseleer (patois à Bruxelles)? réponse: ca se dit "non, peut etre")

Ensuite, il y a les langages courremment appelés "langages de troisième génération" quand on parle de langages de programmation.

On dit généralement qu'il s'agit de langages "proche du langage humain", simplement parce que n'importe qui est en mesure d'arriver à comprendre ce qui est écrit:

for(), do...while, if..., else, printf et tous les autres mots clé de ces langages sont facilement compréhensibles par nous, pour autant que l'on connaisse un tant soit peu l'anglais (en tout cas pour le C et d'autres langages).

Ces langages sont à envisager de manière beaucoup plus stricte que le langage que l'on utilise pour discuter entre nous...

Qu'on fasse une faute d'orthographe, que l'on oublie une virgule, deux point, un point virgule, que l'on mette une majuscule là ou il n'en faut pas, ou qu'on n'en mette pas là ou il en faut, que l'on ne respecte pas scrupuleusement la syntaxe ou la grammaire imposée par le langage, et le programme en charge de gérer le code que l'on a écrit ne sera pas en mesure de faire son travail...

Il ne faut en effet pas oublier que le compilateur (dans le cas du C, en collaboration avec le preprocesseur et l'éditeur de lien) ou l'interpréteur (pour le PHP ou python, par exemple), n'est jamais... qu'un programme... et qu'il souffre de la meme limitation que tous les programmes, à savoir qu'il ne dispose que ... de l'intelligence que l'on a su/pu/voulu lui donner...

Enfin, et là, on va au fond du fonctionnement du processeur, il y a le langage machine, dont il n'est pas tout à fait faux d'estimer que l'assembleur n'est qu'une transcription... parce qu'on a plus facile à retenir que ADDA ajoute une valeur à l'accu A plutot que la valeur hexadécimale (ou pire en binaire) de l'instruction équivalente.

Ce type de langage n'a en fait une existance que parce que le processeur dispose d'un jeu d'instructions correspondant.

Comme tout ce que l'ordinateur peut gérer, du point de vue du processseur, ce sont des 0 et des 1 (et encore, c'est une convention, vu qu'il gère le fait qu'il recoive ou non du courent à un endroit donné), les instructions ne peuvent pas etre fournies au processeur sous une autre forme... Simplement, comme je l'ai indiqué plus haut, pour notre facilité (encore une fois) on utilise plutot la notation hexadécimale...

Généralement, il est très difficile, une fois qu'on en est au stade du langage machine, de récupérer le code source original (certains outils y arrivent, mais de manière relativement limitée )... simplement parce que plusieurs manières de faire peuvent très bien amener à un code "machine" fort semblable (il n'y a jamais de mauvaise manière de faire en informatique... il n'y a que des manières dont certaines seront, dans un contexte donné, plus efficaces que d'autres ) Un simple exemple de ce que j'explique se trouve dans la manière d'implémenter les boucles...

Une boucle "pour" (incrémentale) du genre de for(i=0;i<10;i++) n'a, sommes toutes que peut de différence avec une boucle "tant" (qui donnerait un code du genre de i=0 while(i<10){ ce qu'il faut faire et à la fin i++} ) et la seule différence entre une boucle "tant" et une boucle "jusque" (do{}while), c'est le moment auquel est effectué le premier test: avant d'entrer la première fois dans la boucle, ou, au contraire, apres avoir effectué une première fois le bloc d'instructions de la boucle...

J'écrivais plus haut que l'on pouvait estimer que l'assembleur n'est qu'une transcription du langage machine... Pour etre tout à fait honnete, ce n'est pas vraiment le cas.

L'assembleur utilise ce qu'on appelle des "mnémoniques", genre de moyens mnémotechniques pour se rappeler du but recherché par une instruction donnée.

Selon les architectures (car, rappelons le, il n'y a pas que le PC comme ordinateur ) on peut estimer que tous les processeurs disposent à peu pres des memes instructions... mais qu'une instruction peut avoir une valeur différente sur un processeur PC que sur un processeur prévu pour tourner sur Mac ou SPARK...

En conclusion, je voudrais dire que le langage machine "pur" (donc, à l'exception de l'assemble: le vrai jeu d'instruction du processeur) n'a un intéret que... pour le fondeur, celui qui veut créer un assembleur pour le processeur ou les quelques fondus qui voudraient créer directement un fichier "objet" en binaire (ou qui veulent "débeuguer" une application qui s'obstine à demander un numéro de série )...

A l'heure actuelle, l'assembleur n'a plus énormément plus d'intéret pour le programmeur que le langage machine, à moins de réellement le connaitre sur le bout des doigts, de savoir précisément combien de cycle d'horloge prend chaque instruction et dans le cas expresse où chaque cycle d'horloge du processeur compte, pour une optimisation "super fine"... Au mieux, on pourrait estimer qu'il peut etre intéressant "pour une grosse majorité des gens" de le connaitre un peu pour "la culture générale"

Ce qui importe, à l'heure actuelle pour un programmeur (qu'il soit "amateur" ou "professionnel"), c'est de connaitre le(s) langage(s) de troisième génération qu'il utilise et les concepts lui permettant de créer la logique "la moins mauvaise possible"(à défaut d'être la meilleure) pour arriver à un but donné (en fait, une ou plusieurs bonne(s) méthode(s) d'algorithmie).

Si tu débutes en C, je rejoins enfin tout à fait l'avis de Jean-Marc: t'attaquer aux quatre millions de lignes de code du noyau de linux (qui ne sert qu'à donner la possiblité de gérer les transmissions entre le processeur et tout ce qui y est rattaché directement ou indirectement) est sans doute le plus sur moyen de te dégouter à jamais de la programmation...

Au début, tu auras déjà du mal avec des applications presque aussi simples qu'inutiles (mais juste pour l'entrainement) de quelques centaines de lignes (et parfois moins)... que tu auras écrite de ta main... alors que dire d'une logiciel 40 000 fois plus important dont tu n'as, à ce jour, pas écrit la moindre ligne...

Et pourtant, comme il faut savoir marcher avant de vouloir courrir, il faudra bien que tu passe par ces applications "simples et inutiles" de quelques dizaines/centaines de lignes "pour te faire la main"