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)
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.
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails- utilise du code assembleur (notamment parce que les instructions machine d'addition avec retenue très utiles en arithmetique double précision ne sont pas accessibles en C99, mais GCC fournit https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html & https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...) mais la très grosse majorité de GMP est codée en C, pas en assembleur. Seul le sous repertoire mpn/x86_64 visible en https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source de GMP contient des fichiers assembleurs (pour x86-64).
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble bien que sur une machine donnée, les trois quarts au moins du code binaire d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers assembleurs.
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 12/29/2015 06:42 PM, Vincent Lefevre wrote:
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.
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les
détails- utilise du code assembleur (notamment parce que les
instructions machine d'addition avec retenue très utiles en arithmetique
double précision ne sont pas accessibles en C99, mais GCC fournit
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html &
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...) mais
la très grosse majorité de GMP est codée en C, pas en assembleur. Seul
le sous repertoire mpn/x86_64 visible en
https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source de
GMP contient des fichiers assembleurs (pour x86-64).
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me
semble bien que sur une machine donnée, les trois quarts au moins du
code binaire d'une librarie libgmp.so proviennent de fichiers C, pas de
fichiers assembleurs.
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-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.
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails- utilise du code assembleur (notamment parce que les instructions machine d'addition avec retenue très utiles en arithmetique double précision ne sont pas accessibles en C99, mais GCC fournit https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html & https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...) mais la très grosse majorité de GMP est codée en C, pas en assembleur. Seul le sous repertoire mpn/x86_64 visible en https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source de GMP contient des fichiers assembleurs (pour x86-64).
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble bien que sur une machine donnée, les trois quarts au moins du code binaire d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers assembleurs.
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} ***
very interesting language, pretty easy to learn, make low level a snap
Euh, aurais-tu déjà commencé à arroser la nouvelle année? ;oP
peut-être. Je suis abonné aussi à la liste anglaise, du coup je ne sais pas trop d'ou viennent le posts :-)
bref FORTH est un langage très sympa à tester, plutôt pour usage individuel que collectif, mis il et très facile de coder en haut niveau et de basculer au code machine ensuite au besoin
very interesting language, pretty easy to learn, make low
level a snap
Euh, aurais-tu déjà commencé à arroser la nouvelle année?
;oP
peut-être. Je suis abonné aussi à la liste anglaise, du coup je ne sais
pas trop d'ou viennent le posts :-)
bref FORTH est un langage très sympa à tester, plutôt pour usage
individuel que collectif, mis il et très facile de coder en haut niveau
et de basculer au code machine ensuite au besoin
very interesting language, pretty easy to learn, make low level a snap
Euh, aurais-tu déjà commencé à arroser la nouvelle année? ;oP
peut-être. Je suis abonné aussi à la liste anglaise, du coup je ne sais pas trop d'ou viennent le posts :-)
bref FORTH est un langage très sympa à tester, plutôt pour usage individuel que collectif, mis il et très facile de coder en haut niveau et de basculer au code machine ensuite au besoin
jdd
Vincent Lefevre
On 2015-12-31 11:23:35 +0100, Basile Starynkevitch wrote:
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails- utilise du code assembleur (notamment parce que les instructions machine d'addition avec retenue très utiles en arithmetique double précision ne sont
multiprécision (avec des entiers), pas double précision (qui fait référence à un format virgule flottante).
pas accessibles en C99, mais GCC fournit https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html & https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...)
En fait, le problème est probablement que GCC ne sait pas bien optimiser certains codes. Soit on a le code assembleur en tête, et autant écrire directement en assembleur (on est sûr que le compilateur ne "désoptimise" pas de l'assembleur qui serait retranscrit en C), soit on écrit du code C de manière un peu arbitraire pour tous les processeurs, et une optimisation demanderait des transformations non triviales pour certains processeurs.
Si quelqu'un veut essayer du code C semi-générique, i.e. C avec builtins de GCC, et comparer avec le code assembleur...
mais la très grosse majorité de GMP est codée en C, pas en assembleur.
C'est normal: GMP est écrit par couches. J'aurais peut-être dû préciser: la couche basse (mpn) de GMP. Cela fait tout de même pas mal de fonctions. C'est non négligeable.
Seul le sous repertoire mpn/x86_64 visible en https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source de GMP contient des fichiers assembleurs (pour x86-64).
Idem pour chaque processeur (parfois il n'existe que le code générique en C, mais c'est normalement du C ISO, sans builtins). Et note que pour chaque architecture (e.g. x86_64), il y a du code spécifique pour chaque sous-architecture (environ une dizaine pour x86_64). Au total, ça fait beaucoup de code assembleur!
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble bien que sur une machine donnée, les trois quarts au moins du code binaire d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers assembleurs.
Peut-être, mais si tu fais le total pour toutes les machines, le code assembleur devient important.
On 2015-12-31 11:23:35 +0100, Basile Starynkevitch wrote:
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails-
utilise du code assembleur (notamment parce que les instructions machine
d'addition avec retenue très utiles en arithmetique double précision ne sont
multiprécision (avec des entiers), pas double précision (qui fait
référence à un format virgule flottante).
pas accessibles en C99, mais GCC fournit
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html &
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...)
En fait, le problème est probablement que GCC ne sait pas bien
optimiser certains codes. Soit on a le code assembleur en tête,
et autant écrire directement en assembleur (on est sûr que le
compilateur ne "désoptimise" pas de l'assembleur qui serait
retranscrit en C), soit on écrit du code C de manière un peu
arbitraire pour tous les processeurs, et une optimisation
demanderait des transformations non triviales pour certains
processeurs.
Si quelqu'un veut essayer du code C semi-générique, i.e. C avec
builtins de GCC, et comparer avec le code assembleur...
mais la très grosse majorité de GMP est codée en C, pas en
assembleur.
C'est normal: GMP est écrit par couches. J'aurais peut-être dû
préciser: la couche basse (mpn) de GMP. Cela fait tout de même
pas mal de fonctions. C'est non négligeable.
Seul le sous repertoire mpn/x86_64 visible en
https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source
de GMP contient des fichiers assembleurs (pour x86-64).
Idem pour chaque processeur (parfois il n'existe que le code générique
en C, mais c'est normalement du C ISO, sans builtins). Et note que
pour chaque architecture (e.g. x86_64), il y a du code spécifique
pour chaque sous-architecture (environ une dizaine pour x86_64).
Au total, ça fait beaucoup de code assembleur!
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble
bien que sur une machine donnée, les trois quarts au moins du code binaire
d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers
assembleurs.
Peut-être, mais si tu fais le total pour toutes les machines, le code
assembleur devient important.
On 2015-12-31 11:23:35 +0100, Basile Starynkevitch wrote:
Oui et non. C'est vrai que GMP -voir http://gmplib.org/ pour les détails- utilise du code assembleur (notamment parce que les instructions machine d'addition avec retenue très utiles en arithmetique double précision ne sont
multiprécision (avec des entiers), pas double précision (qui fait référence à un format virgule flottante).
pas accessibles en C99, mais GCC fournit https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html & https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html ...)
En fait, le problème est probablement que GCC ne sait pas bien optimiser certains codes. Soit on a le code assembleur en tête, et autant écrire directement en assembleur (on est sûr que le compilateur ne "désoptimise" pas de l'assembleur qui serait retranscrit en C), soit on écrit du code C de manière un peu arbitraire pour tous les processeurs, et une optimisation demanderait des transformations non triviales pour certains processeurs.
Si quelqu'un veut essayer du code C semi-générique, i.e. C avec builtins de GCC, et comparer avec le code assembleur...
mais la très grosse majorité de GMP est codée en C, pas en assembleur.
C'est normal: GMP est écrit par couches. J'aurais peut-être dû préciser: la couche basse (mpn) de GMP. Cela fait tout de même pas mal de fonctions. C'est non négligeable.
Seul le sous repertoire mpn/x86_64 visible en https://gmplib.org/repo/gmp-6.1/file/tip/mpn/x86_64 du code source de GMP contient des fichiers assembleurs (pour x86-64).
Idem pour chaque processeur (parfois il n'existe que le code générique en C, mais c'est normalement du C ISO, sans builtins). Et note que pour chaque architecture (e.g. x86_64), il y a du code spécifique pour chaque sous-architecture (environ une dizaine pour x86_64). Au total, ça fait beaucoup de code assembleur!
Je n'ai pas fait le compte des lignes de code dans GMP, mais il me semble bien que sur une machine donnée, les trois quarts au moins du code binaire d'une librarie libgmp.so proviennent de fichiers C, pas de fichiers assembleurs.
Peut-être, mais si tu fais le total pour toutes les machines, le code assembleur devient important.
Qui a écrit que l'Assembleur n'était plus beaucoup utilisé :
KolibriOS est un système d'exploitation, tout petit mais incroyablement optimisé (OS Libre, publié en majorité sous licence GPL v2).
Ces performances sont atteintes grâce à l'écriture du coeur de KolibriOS (noyau et pilotes) en langage * assembleur FASM * : https://fr.wikipedia.org/wiki/FASM
Du fait de cette optimisation, il ne nécessite que quelques megaoctets d'espace disque et seulement 8Mo de mémoire vive.
Le système démarre en moins de 10 secondes sur un PC à 100€, de l'allumage à l'affichage de l'interface graphique.
Les applications se lancent instantanément, sans avoir à supporter de pointeur en forme de sablier.
La rapidité et le peu de mémoire nécessaire sont probablement plus dûs à la simplicité du système qu'au fait que ce soit programmé en assembleur.
On 2016-01-01 22:50:37 +0100, andre_debian@numericable.fr wrote:
Qui a écrit que l'Assembleur n'était plus beaucoup utilisé :
KolibriOS est un système d'exploitation, tout petit mais incroyablement
optimisé (OS Libre, publié en majorité sous licence GPL v2).
Ces performances sont atteintes grâce à l'écriture du coeur de KolibriOS
(noyau et pilotes) en langage * assembleur FASM * :
https://fr.wikipedia.org/wiki/FASM
Du fait de cette optimisation, il ne nécessite que quelques megaoctets
d'espace disque et seulement 8Mo de mémoire vive.
Le système démarre en moins de 10 secondes sur un PC à 100€, de
l'allumage à l'affichage de l'interface graphique.
Les applications se lancent instantanément, sans avoir à supporter
de pointeur en forme de sablier.
La rapidité et le peu de mémoire nécessaire sont probablement plus
dûs à la simplicité du système qu'au fait que ce soit programmé en
assembleur.
Qui a écrit que l'Assembleur n'était plus beaucoup utilisé :
KolibriOS est un système d'exploitation, tout petit mais incroyablement optimisé (OS Libre, publié en majorité sous licence GPL v2).
Ces performances sont atteintes grâce à l'écriture du coeur de KolibriOS (noyau et pilotes) en langage * assembleur FASM * : https://fr.wikipedia.org/wiki/FASM
Du fait de cette optimisation, il ne nécessite que quelques megaoctets d'espace disque et seulement 8Mo de mémoire vive.
Le système démarre en moins de 10 secondes sur un PC à 100€, de l'allumage à l'affichage de l'interface graphique.
Les applications se lancent instantanément, sans avoir à supporter de pointeur en forme de sablier.
La rapidité et le peu de mémoire nécessaire sont probablement plus dûs à la simplicité du système qu'au fait que ce soit programmé en assembleur.
