Documentation complète sur la compilation de programmes

Bonjour,

pour information, les bonnes pratiques "indenter son code" et
"commenter son code" n'ont strictement rien à voir avec le processus
de compilation des programmes.

Elles n'en présentent pas moins d'intérêt: elles facilitent la bonne
compréhension du code par les humains qui le modifient, ce qui
contribue à diminuer le risque de bugs...

bonnes fêtes

______________
Éric Dégenètais
Henix



http://www.henix.com
http://www.squashtest.org


Le 23 décembre 2015 à 17:43, enae <philolilou@free.fr> a écr it :

Bonjour,

j'utilise quotidiennement de nombreux programmes pour toute tâche.

Après examen de tutoriels, livres de programmations et autres ressou rces, 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 c e faire il faut utiliser des options -o etc...
Mais existe-t-il réellement un manuel complet (ou ressource informat ique) abordant de façon concrète, claire et en profondeur les poi nts suivants:
- les différentes étapes du processus de compilation, leur util ité, le fonctionnement en détail de celles-ci
- toutes les options possibles, chacune étant expliquée en prof ondeur
- 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)

Je vous remercie d'avance pour votre aide.

Bonsoir,

je vous remercie pour votre remarque pertinente qui me fait remarquer
qu'effectivement, les bonnes pratiques au niveau code n'interviennent
pas dans le processus de compilation.

Cependant, existe-t-il des bonnes pratiques au niveau de la compilation
en elle-même?

Par ailleurs, auriez-vous plus d'informations quant aux autres points de
ma demande?

Je vous remercie d'avance pour votre aide.

Bonnes fêtes à tous.



Le 23/12/2015 17:57, Eric Degenetais a écrit :

Bonjour,

pour information, les bonnes pratiques "indenter son code" et
"commenter son code" n'ont strictement rien à voir avec le processus
de compilation des programmes.

Elles n'en présentent pas moins d'intérêt: elles facilitent la bonne
compréhension du code par les humains qui le modifient, ce qui
contribue à diminuer le risque de bugs...

bonnes fêtes

______________
Éric Dégenètais
Henix



http://www.henix.com
http://www.squashtest.org


Le 23 décembre 2015 à 17:43, enae <philolilou@free.fr> a écrit :

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)

Je vous remercie d'avance pour votre aide.

On 12/23/2015 05:43 PM, enae wrote:
[...]

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

En principe, il ne peut pas exister de resources universelles décrivant
comment compiler un programme, pour la bonne raison que d'un compilateur
à l'autre, et d'un language à l'autre, le processus de compilation est
très différent.

Concrètement, compiler un programme dont le code source est codé en C et
un programme dont le code source est codé en Ocaml ou en Common Lisp est
vraiment très différent, notamment parce que dans le détail "compiler"
veut dire des choses différentes, et qu'il y a peut-être différentes
façons de compiler (le développeur ou le contributeur occasionnel de
patch va compiler avec des options de déboguage; l'utilisateur et le
packageur -celui qui fait un paquet Debian- préfère compiler avec des
options d'optimisations).

D'autre part, un logiciel libre suffisamment complexe utilisera souvent
ce qu'on peut appeler pompeusement des techniques de méta-programmation:
une partie du code source en C (par exemple) serait alors générée. Par
exemple le compilateur GCC a actuellement plus d'une douzaine de
générateurs spécialisés de code C++ qui genèrent une petite partie du
compilateur, la grande majorité étant du C++; et certains de ses
generateurs (pour GCC, gengtype par exemple) sont très spécifiques à
l'application.


La plupart des logiciels libres ont des instructions de compilation,
souvent en anglais techniques (donc assez lisible), par exemple dans un
fichier README ou INSTALL.

J'aurais tendance à suggérer de commencer à compiler un petit logiciel
libre; ainsi il est plus simple de compiler GNU bash ou GNU coreutils
que de compiler le compilateur GCC ou le noyau Linux.

Il y a aussi la question de la configuration du logiciel (une première
étape de l'installation est souvent de lancer un script, par exemple
./configure, qui vérifie quels outils sont disponibles sur le système et
génère des fichiers de configuration ad-hoc). Et la question, très liée
à la configuration, de la dépendance de paquets existants.

Si on veut viser la généralité la plus forte, ces thématiques sont
encore des sujets de recherche académiques (et on peut faire une thèse
de doctorat, y compris en France, sur ces questions).

Bonne année à tous!



--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

On 2015-12-26 20:18:56 +0100, Basile Starynkevitch wrote:

Il y a aussi la question de la configuration du logiciel (une
première étape de l'installation est souvent de lancer un script,
par exemple ./configure, qui vérifie quels outils sont disponibles
sur le système et génère des fichiers de configuration ad-hoc). Et
la question, très liée à la configuration, de la dépendance de
paquets existants.

Et le script configure est lui-même généralement généré par les
autotools (autoconf, automake, libtool).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

On 2015-12-23 17:57:44 +0100, Eric Degenetais wrote:

pour information, les bonnes pratiques "indenter son code" et
"commenter son code" n'ont strictement rien à voir avec le processus
de compilation des programmes.

sauf pour python. :((((

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Le 23/12/2015 17:43, enae a écrit :

Bonjour,

- les différentes étapes du processus de compilation, leur utilité, le
fonctionnement en détail de celles-ci

Pour débuter (pour GCC) :

http://codingfreak.blogspot.com/2008/02/compilation-process-in-gcc.html

- 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)

C'est un projet de Bac+ 2 ???


J.


--
GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/

Bonjour,

je remercie les personnes ayant pris le temps de me répondre.

Pour répondre à la question de Jacques, ce n'est pas un projet bac +2,
c'est simplement de l'intéressement personnel et la volonté d'en savoir
un peu plus sur cette boite obscure qu'est un compilateur de programmes,
ainsi que la volonté d'essayer de comprendre en profondeur tout ceci, la
difficulté étant principalement qu'il y a peu de ressources traitant du
sujet, ce pourquoi je fais appel à la liste.

Je remercie particulièrement Basile pour son explication ci-dessous.
Visiblement, la question ne semble pas être simple et mérite donc un
approfondissement de celle-ci.

J'aurai une petite question complémentaire:
vu que les compilateurs génèrent du "code machine", j'aurai tendance à
dire que les langages compilés sont syntaxiquement de "haut niveau" par
opposition à un langage type "assembleur". Suis-je dans le vrai?

Merci d'avance pour votre réponse et votre éclairage.


Le 26/12/2015 20:18, Basile Starynkevitch a écrit :

On 12/23/2015 05:43 PM, enae wrote:
[...]

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

En principe, il ne peut pas exister de resources universelles
décrivant comment compiler un programme, pour la bonne raison que d'un
compilateur à l'autre, et d'un language à l'autre, le processus de
compilation est très différent.

Concrètement, compiler un programme dont le code source est codé en C
et un programme dont le code source est codé en Ocaml ou en Common
Lisp est vraiment très différent, notamment parce que dans le détail
"compiler" veut dire des choses différentes, et qu'il y a peut-être
différentes façons de compiler (le développeur ou le contributeur
occasionnel de patch va compiler avec des options de déboguage;
l'utilisateur et le packageur -celui qui fait un paquet Debian-
préfère compiler avec des options d'optimisations).

D'autre part, un logiciel libre suffisamment complexe utilisera
souvent ce qu'on peut appeler pompeusement des techniques de
méta-programmation: une partie du code source en C (par exemple)
serait alors générée. Par exemple le compilateur GCC a actuellement
plus d'une douzaine de générateurs spécialisés de code C++ qui
genèrent une petite partie du compilateur, la grande majorité étant du
C++; et certains de ses generateurs (pour GCC, gengtype par exemple)
sont très spécifiques à l'application.


La plupart des logiciels libres ont des instructions de compilation,
souvent en anglais techniques (donc assez lisible), par exemple dans
un fichier README ou INSTALL.

J'aurais tendance à suggérer de commencer à compiler un petit logiciel
libre; ainsi il est plus simple de compiler GNU bash ou GNU coreutils
que de compiler le compilateur GCC ou le noyau Linux.

Il y a aussi la question de la configuration du logiciel (une
première étape de l'installation est souvent de lancer un script, par
exemple ./configure, qui vérifie quels outils sont disponibles sur le
système et génère des fichiers de configuration ad-hoc). Et la
question, très liée à la configuration, de la dépendance de paquets
existants.

Si on veut viser la généralité la plus forte, ces thématiques sont
encore des sujets de recherche académiques (et on peut faire une thèse
de doctorat, y compris en France, sur ces questions).

Bonne année à tous!

On Sunday 27 December 2015 21:50:04 enae wrote:

J'aurai une petite question complémentaire:
vu que les compilateurs génèrent du "code machine", j'aurai ten dance à
dire que les langages compilés sont syntaxiquement de "haut niveau" par
opposition à un langage type "assembleur". Suis-je dans le vrai?

Le langage assembleur est très proche du langage machine, le langage
qu'utilise l'ordinateur, des informations en binaire, 0 et 1.
Il dépend donc du processeur. Ainsi il n'existe pas un langage assembl eur,
mais un langage assembleur par type de processeur. Il est nécessaire d e
connaître un minimum le fonctionnement d'un processeur pour pouvoir ab order
cette partie.
Pour éviter de taper des programmes avec des 0 et des 1, (ou en hexa) c'est
impossible, on utilise des mnémoniques (instructions) basiques.
LDA <value> (load register A), MOV, ADD..., STA <value> (stock register A).

L'assembleur est recommandé pour l'informatique embarquée,
microprocesseur 16 bits (pardon et misère les 64 bits !).
On peut utiliser des instructions macro-assembleurs pour des programmes
plus sophistiqués.
Pour créer un logiciel sophistiqué, un langage "de haut niveau" e st hautement
recommandé (avec souvent l'option POO Programmation Orientée Obje t).

André

On 12/27/2015 09:50 PM, enae wrote:

Bonjour,
J'aurai une petite question complémentaire:
vu que les compilateurs génèrent du "code machine", j'aurai tendance à
dire que les langages compilés sont syntaxiquement de "haut niveau"
par opposition à un langage type "assembleur". Suis-je dans le vrai?

L'assembleur n'est quasiment plus utilisé (sauf peut-être dans
l'embarqué de bas niveau, sur des petits microcontroleurs 8 bits avec
quelques kilo-octets de mémoire). Un compilateur optimiseur génère
aujourdhui un code plus rapide que n'est capable de coder un
developpeur humain experimenté en assembleur. Et de nos jours des
processeurs de marques différentes (par exemple AMD et Intel) executent
le même jeu d'instruction différemment. Concrètement un compilateur
optimiseur va générer du code un peu différent pour un AMD

Par contre, certains langages (principalement le C) permettent de
mélanger un peu de code assembleur avec beaucoup d'autre code (en C). Et
certaines fonctions ne peuvent pas être codées en C (par exemple, la
fonction longjmp du standard C).

A mon avis, il y a plusieurs niveaux de langages, et tous les langages
ne sont pas de haut niveau. En particulier, le langage C est un langage
de bas niveau, proche de la machine. Il existe des langages de plus haut
niveau, par exemple Ocaml ou Common Lisp ou Prolog ou Clojure ou Scala.
Ces langages sont plus concis et plus expressifs que le langage C.
Parfois, un langage de haut niveau est compilé en du code C.
http://programmers.stackexchange.com/a/257873/40065
http://bootstrappingartificialintelligence.fr/WordPress3/2014/01/stop-programming/


Pour un panorama de plusieurs langages de programmation, voir
http://www.cs.rochester.edu/~scott/pragmatics/

Bonne année à tous!

PS. Pour enae: il est difficile de répondre plus précisément sans savoir
si vous savez programmer, et quels languages de programmation connaissez
vou...

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

On 2015-12-28 10:49:07 +0100, Basile Starynkevitch wrote:

L'assembleur n'est quasiment plus utilisé (sauf peut-être dans l'embarqué de
bas niveau, sur des petits microcontroleurs 8 bits avec quelques kilo-octets
de mémoire).

Il est très utilisé par GMP, car le langage C (qui est pourtant celui
de plus bas niveau) n'est pas vraiment conçu pour implémenter de la
multiprécision à base d'entiers.

Un compilateur optimiseur génère aujourdhui un code plus rapide
que n'est capable de coder un developpeur humain experimenté en assembleur.
Et de nos jours des processeurs de marques différentes (par exemple AMD et
Intel) executent le même jeu d'instruction différemment. Concrètement un
compilateur optimiseur va générer du code un peu différent pour un AMD

Il y a même des différences entre les divers types de processeurs
d'une même marque. GMP exploite cela. À mon labo, j'ai ainsi
7 bibliothèques GMP complilées x86_64, suivant la machine.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)