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!

[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.