Documentation complète sur la compilation de programmes
57 réponses
enae
Bonjour,
j'utilise quotidiennement de nombreux programmes pour toute tâche.
Après examen de tutoriels, livres de programmations et autres
ressources, je continue de me poser des questions sur le processus de
compilation de programmes.
Certes, le fichier sources est traduit en langage machine, certes, pour
ce faire il faut utiliser des options -o etc...
Mais existe-t-il réellement un manuel complet (ou ressource
informatique) abordant de façon concrète, claire et en profondeur les
points suivants:
- les différentes étapes du processus de compilation, leur utilité, le
fonctionnement en détail de celles-ci
- toutes les options possibles, chacune étant expliquée en profondeur
- des explications sur l'impact hardware lié à la compilation
- la compilation croisée
- les bonnes pratiques de programmation (exemple: indenter son code et
le commenter)
Le 5 janvier 2016 à 17:56, a écrit : > On voit qu'il serait impossible de programmer > en hexadécimal et pire en code machine,
Juste atrocement fastidieux...pour avoir fait les deux à petite dose il y a presque 25 ans, pas énormément plus qu'en assembleur (qui pour simpli fier à plaquer des mnémoniques sur les instructions, mais en terme de verbosit é et de progression par sauts de puce c'est du même accabit). Il y a encore des gens qui manipulent ces formes de code pour des cas de niche: -hackers cherchant à caser du code dans un débordement de pile l'air d e rien - spécialistes qui conçoivent les assembleurs, linkers et autres désassembleurs (faut bien les écrire...) - ceux qui conçoivent les les processeurs - gens qui aiment "le sport" - j'en oublie sans doute... Ceci dit, je suis d'accord, dans le cas général on limite drastiqueme nt sa consommation d'aspirine à utiliser les langages de niveaux supérieurs ... bonne soirée :) Éric Dégenètais
Et sans oublier ceux qui ont débuté l'informatique il n'y a pas si longtemps, pas de mode graphique, pas de souris, que le clavier, avec du code blanc sur fond noir, selon un shell dépendant du système, des artifices pour ne pas trop utiliser la mémoire, très chère à l'époque, pas de disques durs mais des bandes magnétiques...
Et c'est vrai, certains sont encore nostalgiques de cette période de l'informatique "héroïque", comme ceux qui restent attachés aux Dauphine Renault, traction Citroën, 404 Peugeot... sans aucune électronique, facilement réparables dans son petit garage :-)
André
On Tuesday 05 January 2016 18:10:47 you wrote:
Le 5 janvier 2016 à 17:56, <andre_debian@numericable.fr> a écrit :
> On voit qu'il serait impossible de programmer
> en hexadécimal et pire en code machine,
Juste atrocement fastidieux...pour avoir fait les deux à petite dose il y a
presque 25 ans, pas énormément plus qu'en assembleur (qui pour simpli fier à
plaquer des mnémoniques sur les instructions, mais en terme de verbosit é et
de progression par sauts de puce c'est du même accabit).
Il y a encore des gens qui manipulent ces formes de code pour des cas de
niche:
-hackers cherchant à caser du code dans un débordement de pile l'air d e rien
- spécialistes qui conçoivent les assembleurs, linkers et autres
désassembleurs (faut bien les écrire...)
- ceux qui conçoivent les les processeurs
- gens qui aiment "le sport"
- j'en oublie sans doute...
Ceci dit, je suis d'accord, dans le cas général on limite drastiqueme nt sa
consommation d'aspirine à utiliser les langages de niveaux supérieurs ...
bonne soirée :) Éric Dégenètais
Et sans oublier ceux qui ont débuté l'informatique il n'y a pas si
longtemps, pas de mode graphique, pas de souris,
que le clavier, avec du code blanc sur fond noir,
selon un shell dépendant du système,
des artifices pour ne pas trop utiliser la mémoire,
très chère à l'époque, pas de disques durs mais des bandes
magnétiques...
Et c'est vrai, certains sont encore nostalgiques de cette période
de l'informatique "héroïque",
comme ceux qui restent attachés aux Dauphine Renault, traction Citroën,
404 Peugeot... sans aucune électronique, facilement réparables dans
son petit garage :-)
Le 5 janvier 2016 à 17:56, a écrit : > On voit qu'il serait impossible de programmer > en hexadécimal et pire en code machine,
Juste atrocement fastidieux...pour avoir fait les deux à petite dose il y a presque 25 ans, pas énormément plus qu'en assembleur (qui pour simpli fier à plaquer des mnémoniques sur les instructions, mais en terme de verbosit é et de progression par sauts de puce c'est du même accabit). Il y a encore des gens qui manipulent ces formes de code pour des cas de niche: -hackers cherchant à caser du code dans un débordement de pile l'air d e rien - spécialistes qui conçoivent les assembleurs, linkers et autres désassembleurs (faut bien les écrire...) - ceux qui conçoivent les les processeurs - gens qui aiment "le sport" - j'en oublie sans doute... Ceci dit, je suis d'accord, dans le cas général on limite drastiqueme nt sa consommation d'aspirine à utiliser les langages de niveaux supérieurs ... bonne soirée :) Éric Dégenètais
Et sans oublier ceux qui ont débuté l'informatique il n'y a pas si longtemps, pas de mode graphique, pas de souris, que le clavier, avec du code blanc sur fond noir, selon un shell dépendant du système, des artifices pour ne pas trop utiliser la mémoire, très chère à l'époque, pas de disques durs mais des bandes magnétiques...
Et c'est vrai, certains sont encore nostalgiques de cette période de l'informatique "héroïque", comme ceux qui restent attachés aux Dauphine Renault, traction Citroën, 404 Peugeot... sans aucune électronique, facilement réparables dans son petit garage :-)
André
jdd
Le 05/01/2016 18:10, Eric Degenetais a écrit :
* hackers cherchant à caser du code dans un débordement de pile l'air de rien
ou pour casser une protection :-)
j'ai joué à ca il y a longtemps :-)
jdd
Le 05/01/2016 18:10, Eric Degenetais a écrit :
* hackers cherchant à caser du code dans un débordement de pile l'air
de rien
* hackers cherchant à caser du code dans un débordement de pile l'air de rien
ou pour casser une protection :-)
j'ai joué à ca il y a longtemps :-)
jdd
Philippe Gras
Et c'est vrai, certains sont encore nostalgiques de cette période de l'informatique "héroïque", comme ceux qui restent attachés aux Dauphine Renault, traction Citroën, 404 Peugeot... sans aucune électronique, facilement réparables dans son petit garage :-)
André
On peut douter que les mêmes soient nostalgiques des vieux ordinateurs et des vieilles voitures, parce qu'il n'y a justement pas d'électronique.
Quoique :-D
Ph. Gras=
Et c'est vrai, certains sont encore nostalgiques de cette période
de l'informatique "héroïque",
comme ceux qui restent attachés aux Dauphine Renault, traction Citroën,
404 Peugeot... sans aucune électronique, facilement réparables dans
son petit garage :-)
André
On peut douter que les mêmes soient nostalgiques des vieux ordinateurs
et des vieilles voitures, parce qu'il n'y a justement pas d'électronique.
Et c'est vrai, certains sont encore nostalgiques de cette période de l'informatique "héroïque", comme ceux qui restent attachés aux Dauphine Renault, traction Citroën, 404 Peugeot... sans aucune électronique, facilement réparables dans son petit garage :-)
André
On peut douter que les mêmes soient nostalgiques des vieux ordinateurs et des vieilles voitures, parce qu'il n'y a justement pas d'électronique.
On Tuesday 05 January 2016 19:11:56 Philippe Gras wrote:
> Et c'est vrai, certains sont encore nostalgiques de cette période > de l'informatique "héroïque", > comme ceux qui restent attachés aux Dauphine Renault, traction Citro ën, > 404 Peugeot... sans aucune électronique, facilement réparables dans > son petit garage :-) André > On peut douter que les mêmes soient nostalgiques des vieux ordinateurs et des vieilles voitures, parce qu'il n'y a justement pas d'électroniqu e. Quoique :-D Ph. Gras
Un ordinateur, c'est de l'électronique avec une interface appelée informatique.
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
Il faut aussi différencier l'électronique numérique (0 et 1) et analo gique, toutes tensions faibles.
On Tuesday 05 January 2016 19:11:56 Philippe Gras wrote:
> Et c'est vrai, certains sont encore nostalgiques de cette période
> de l'informatique "héroïque",
> comme ceux qui restent attachés aux Dauphine Renault, traction Citro ën,
> 404 Peugeot... sans aucune électronique, facilement réparables dans
> son petit garage :-) André
>
On peut douter que les mêmes soient nostalgiques des vieux ordinateurs
et des vieilles voitures, parce qu'il n'y a justement pas d'électroniqu e.
Quoique :-D Ph. Gras
Un ordinateur, c'est de l'électronique avec une interface appelée
informatique.
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
Il faut aussi différencier l'électronique numérique (0 et 1) et analo gique,
toutes tensions faibles.
On Tuesday 05 January 2016 19:11:56 Philippe Gras wrote:
> Et c'est vrai, certains sont encore nostalgiques de cette période > de l'informatique "héroïque", > comme ceux qui restent attachés aux Dauphine Renault, traction Citro ën, > 404 Peugeot... sans aucune électronique, facilement réparables dans > son petit garage :-) André > On peut douter que les mêmes soient nostalgiques des vieux ordinateurs et des vieilles voitures, parce qu'il n'y a justement pas d'électroniqu e. Quoique :-D Ph. Gras
Un ordinateur, c'est de l'électronique avec une interface appelée informatique.
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
Il faut aussi différencier l'électronique numérique (0 et 1) et analo gique, toutes tensions faibles.
jdd
Le 05/01/2016 19:45, a écrit :
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
https://fr.wikipedia.org/wiki/Machine_analytique
jdd
Le 05/01/2016 19:45, andre_debian@numericable.fr a écrit :
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
L'informatique ne peut exister sans l'électronique, mais pas l'inverse.
https://fr.wikipedia.org/wiki/Machine_analytique
jdd
Dominique Asselineau
wrote on Tue, Jan 05, 2016 at 05:56:13PM +0100
On Monday 04 January 2016 21:27:07 enae wrote: > vu qu'un compilateur transforme du code lisible par un humain en code > machine, comment sait-il en quoi il doit transformer ce code lisible par > un humain? > comment connait-on les spécifications du "code machine"? (je devine que > cela est certainement une suite de 0 et de 1, et très certainement > fortement dépendant du processeur et de son architecture) > comment le processeur sait-il ce qu'il a à faire en voyant ce code machine? > comment est chargé ce code machine dans le processeur ? (j'aurai > tendance à penser à grub, mais, à la mise sous tension du processeur, à > t+1 qu'est-ce qui fait le processeur commence à faire une tâche?)
Prenons cet exemple d'une instruction assembleur du processeur Motorola série 6800 :
charger l'accumulateur A (load) de la valeur 1000 (binaire) : LDAA #0X1000 (load A value 1000 binary) Code en hexadécimal : CE 1000 Code machine compréhensible par le processeur : 1100 1110 1000
Exemple plus simple, mettre à zéro l'accumulateur A : CLRA (Clear Accumulateur A) Code en hexadécimal : 4F Code machine compréhensible par le processeur : 0100 1111
Équivalent de RAZ accumulateur A avec load : charger l'accumulateur A (load) de la valeur 0000 (binaire) : LDAA #0X0000 (load A value 0000 binary) Code en hexadécimal : CE 0000 Code machine compréhensible par le processeur : 1100 1110 0000
Le # exprime une valeur binaire. Je ne suis plus sûr si c'est LDAA ou LDA...
On voit qu'il serait impossible de programmer en hexadécimal
Comment ça, impossible. Du temps des machines sur lesquelles les octets étaient comptés, on ne travaillait pas avec des langages compilés qui généraient trop de codes. Et puis comme l'a dit Éric, je crois, le langage d'assemblage n'était que des mnémoniques correspondant aux codes machines. Ça aidait tout de même au calcul des sauts relatifs. mais dire que c'était impossible n'est déjà pas exact.
dom --
andre_debian@numericable.fr wrote on Tue, Jan 05, 2016 at 05:56:13PM +0100
On Monday 04 January 2016 21:27:07 enae wrote:
> vu qu'un compilateur transforme du code lisible par un humain en code
> machine, comment sait-il en quoi il doit transformer ce code lisible par
> un humain?
> comment connait-on les spécifications du "code machine"? (je devine que
> cela est certainement une suite de 0 et de 1, et très certainement
> fortement dépendant du processeur et de son architecture)
> comment le processeur sait-il ce qu'il a à faire en voyant ce code machine?
> comment est chargé ce code machine dans le processeur ? (j'aurai
> tendance à penser à grub, mais, à la mise sous tension du processeur, à
> t+1 qu'est-ce qui fait le processeur commence à faire une tâche?)
Prenons cet exemple d'une instruction assembleur du processeur
Motorola série 6800 :
charger l'accumulateur A (load) de la valeur 1000 (binaire) :
LDAA #0X1000 (load A value 1000 binary)
Code en hexadécimal :
CE 1000
Code machine compréhensible par le processeur :
1100 1110 1000
Exemple plus simple,
mettre à zéro l'accumulateur A :
CLRA (Clear Accumulateur A)
Code en hexadécimal :
4F
Code machine compréhensible par le processeur :
0100 1111
Équivalent de RAZ accumulateur A avec load :
charger l'accumulateur A (load) de la valeur 0000 (binaire) :
LDAA #0X0000 (load A value 0000 binary)
Code en hexadécimal :
CE 0000
Code machine compréhensible par le processeur :
1100 1110 0000
Le # exprime une valeur binaire.
Je ne suis plus sûr si c'est LDAA ou LDA...
On voit qu'il serait impossible de programmer
en hexadécimal
Comment ça, impossible. Du temps des machines sur lesquelles les
octets étaient comptés, on ne travaillait pas avec des langages
compilés qui généraient trop de codes. Et puis comme l'a dit Éric, je
crois, le langage d'assemblage n'était que des mnémoniques
correspondant aux codes machines. Ça aidait tout de même au calcul
des sauts relatifs. mais dire que c'était impossible n'est déjà pas exact.
On Monday 04 January 2016 21:27:07 enae wrote: > vu qu'un compilateur transforme du code lisible par un humain en code > machine, comment sait-il en quoi il doit transformer ce code lisible par > un humain? > comment connait-on les spécifications du "code machine"? (je devine que > cela est certainement une suite de 0 et de 1, et très certainement > fortement dépendant du processeur et de son architecture) > comment le processeur sait-il ce qu'il a à faire en voyant ce code machine? > comment est chargé ce code machine dans le processeur ? (j'aurai > tendance à penser à grub, mais, à la mise sous tension du processeur, à > t+1 qu'est-ce qui fait le processeur commence à faire une tâche?)
Prenons cet exemple d'une instruction assembleur du processeur Motorola série 6800 :
charger l'accumulateur A (load) de la valeur 1000 (binaire) : LDAA #0X1000 (load A value 1000 binary) Code en hexadécimal : CE 1000 Code machine compréhensible par le processeur : 1100 1110 1000
Exemple plus simple, mettre à zéro l'accumulateur A : CLRA (Clear Accumulateur A) Code en hexadécimal : 4F Code machine compréhensible par le processeur : 0100 1111
Équivalent de RAZ accumulateur A avec load : charger l'accumulateur A (load) de la valeur 0000 (binaire) : LDAA #0X0000 (load A value 0000 binary) Code en hexadécimal : CE 0000 Code machine compréhensible par le processeur : 1100 1110 0000
Le # exprime une valeur binaire. Je ne suis plus sûr si c'est LDAA ou LDA...
On voit qu'il serait impossible de programmer en hexadécimal
Comment ça, impossible. Du temps des machines sur lesquelles les octets étaient comptés, on ne travaillait pas avec des langages compilés qui généraient trop de codes. Et puis comme l'a dit Éric, je crois, le langage d'assemblage n'était que des mnémoniques correspondant aux codes machines. Ça aidait tout de même au calcul des sauts relatifs. mais dire que c'était impossible n'est déjà pas exact.
dom --
andre_debian
wrote on Tue, Jan 05, 2016 at 05:56:13PM +0100 > On voit qu'il serait impossible de programmer en hexadécimal
On Tuesday 05 January 2016 20:27:25 Dominique Asselineau wrote:
Comment ça, impossible. Du temps des machines sur lesquelles les octets étaient comptés, on ne travaillait pas avec des langages compilés qui généraient trop de codes. Et puis comme l'a dit Éri c, je crois, le langage d'assemblage n'était que des mnémoniques correspondant aux codes machines. Ça aidait tout de même au calcul des sauts relatifs. mais dire que c'était impossible n'est déjà pa s exact. dom
Ça s'appelle du pinaillage de termes.
C'est quasi impossible, comment écrire et corriger un long programme en hexa, même si ça a existé à un moment, au tout début.
André
andre_debian@numericable.fr wrote on Tue, Jan 05, 2016 at 05:56:13PM +0100
> On voit qu'il serait impossible de programmer en hexadécimal
On Tuesday 05 January 2016 20:27:25 Dominique Asselineau wrote:
Comment ça, impossible. Du temps des machines sur lesquelles les
octets étaient comptés, on ne travaillait pas avec des langages
compilés qui généraient trop de codes. Et puis comme l'a dit Éri c, je
crois, le langage d'assemblage n'était que des mnémoniques
correspondant aux codes machines. Ça aidait tout de même au calcul
des sauts relatifs. mais dire que c'était impossible n'est déjà pa s exact.
dom
Ça s'appelle du pinaillage de termes.
C'est quasi impossible,
comment écrire et corriger un long programme en hexa,
même si ça a existé à un moment, au tout début.
wrote on Tue, Jan 05, 2016 at 05:56:13PM +0100 > On voit qu'il serait impossible de programmer en hexadécimal
On Tuesday 05 January 2016 20:27:25 Dominique Asselineau wrote:
Comment ça, impossible. Du temps des machines sur lesquelles les octets étaient comptés, on ne travaillait pas avec des langages compilés qui généraient trop de codes. Et puis comme l'a dit Éri c, je crois, le langage d'assemblage n'était que des mnémoniques correspondant aux codes machines. Ça aidait tout de même au calcul des sauts relatifs. mais dire que c'était impossible n'est déjà pa s exact. dom
Ça s'appelle du pinaillage de termes.
C'est quasi impossible, comment écrire et corriger un long programme en hexa, même si ça a existé à un moment, au tout début.
André
andre_debian
Le 05/01/2016 19:45, a écrit : > L'informatique ne peut exister sans l'électronique, mais pas l'invers e.
On Tuesday 05 January 2016 19:55:00 jdd pinaille :
https://fr.wikipedia.org/wiki/Machine_analytique
La machine analytique est une machine à calculer programmable, * imaginée * en 1834 par Charles Babbage. * Il ne la réalisera jamais *
Cette machine informatique sans électronique n'a jamais vraiment existé.
Mais l'info de cet ordinateur à vapeur (que Jules Vernes aurait pu invent er dans ses livres) vaut le coup.
Le 05/01/2016 19:45, andre_debian@numericable.fr a écrit :
> L'informatique ne peut exister sans l'électronique, mais pas l'invers e.
On Tuesday 05 January 2016 19:55:00 jdd pinaille :
https://fr.wikipedia.org/wiki/Machine_analytique
La machine analytique est une machine à calculer programmable,
* imaginée * en 1834 par Charles Babbage. * Il ne la réalisera jamais *
Cette machine informatique sans électronique n'a jamais vraiment existé.
Mais l'info de cet ordinateur à vapeur (que Jules Vernes aurait pu invent er
dans ses livres) vaut le coup.
