Re: Documentation complète sur la compilation de programmes

2016-01-10 Par sujet enae 

Bonjour à tous,
et tout d'abord un grand merci à tous les participants à ce fil de 
discussion.
Effectivement, c'est maintenant beaucoup plus clair pour moi, d'autant 
plus que les quelques liens donnent accès à de plus amples 
documentations et à une mine d'informations.


Je vous remercie tous pour votre aide et pour votre participation. ;-)


Le 06/01/2016 01:43, Haricophile a écrit :

Le Tue, 5 Jan 2016 20:27:25 +0100,
Dominique Asselineau  a écrit :


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

L'assembleur se compile aussi pour générer un binaire. L'assembleur
c'est bas niveau : très proche du matériel et de fait du langage
machine, on donne des instructions au processeur, pas aux fenêtres ;)
Je ne dis pas qu'on n'a jamais programmé des instructions directement en
langage machine, mais un langage comme l'assembleur est là pour éviter
ça.

Un langage comme C est suffisamment bas niveau pour permettre d'éviter
d'avoir trop recours à un langage de type assembleur, il y a aussi des
langages spécialisés pour les micro-circuits par exemple qui évitent
ça. Mais l'assembleur n'a pas disparu, on en a encore besoin pour des
usages précis. Pas pour développer une appli de compta bien
sûr. Mais peut même fabriquer un compilateur avec ;)

Re: Documentation complète sur la compilation de programmes

2016-01-06 Par sujet Vincent Lefevre 
On 2016-01-05 18:10:47 +0100, Eric Degenetais wrote:
> 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 simplifier à
> 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 de
>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...

Certains compilateurs, par exemple tcc, qui génère du code machine
sans passer par de l'assembleur.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2016-01-06 Par sujet jdd 

Le 05/01/2016 22:59, andre_deb...@numericable.fr a écrit :

On Tuesday 05 January 2016 22:27:30 jdd wrote:

Le 05/01/2016 22:11, andre_deb...@numericable.fr a écrit :

Cette machine informatique sans électronique n'a jamais vraiment existé.



et les grands classiques:
https://en.wikipedia.org/wiki/Turing_machine
jdd


https://fr.wikipedia.org/wiki/R%C3%A8gle_%C3%A0_calcul
(vendu sur Ebay)
et
La pascaline : https://fr.wikipedia.org/wiki/Pascaline
(prix entre 100 à 400 livres)
et
l'arithmomètre :
https://fr.wikipedia.org/wiki/Arithmom%C3%A8tre

oui, mais celles-là ne sont pas programmables, alors que la machine de 
turing l'était


(les règles à calcul, j'en ai encore une ou deux :-)

jdd

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Raphaël POITEVIN 
Bonjour,
enae  writes:
> 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?)
>
> Cela parait tout bête, et pourtant...
> de nos jours nous avons tellement l'habitude "d'appuyer sur le bouton"
> et cela fonctionne, tout démarre et est fonctionnel.
> Mais il a fallu des années pour en arriver à ce stade, pour qu'une
> simple puce de silicium soit le maître d'oeuvre de tout un système
> autour duquel tourne tant de choses de nos jours.

Cela est loin de répondre à toutes tes questions, mais je t’invite à
t’intéresser à ces conférences :
http://www.college-de-france.fr/site/gerard-berry/_inaugural-lecture.htm

Bien à toi,
-- 
Raphaël
Hypra S.A.S.

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
On Tuesday 05 January 2016 18:10:47 you wrote:
> 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 simplifier à
> 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 de  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 drastiquement 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é

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Eric Degenetais 
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 simplifier à
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 de
   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 drastiquement sa
consommation d'aspirine à utiliser les langages de niveaux supérieurs...
bonne soirée :)

__
Éric Dégenètais
Henix



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

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
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 

Équivalent de RAZ accumulateur A avec load :
charger l'accumulateur A (load) de la valeur  (binaire) :
LDAA #0X  (load A value  binary)
Code en hexadécimal :
CE 
Code machine compréhensible par le processeur :
1100 1110 

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 et pire en code machine,
d'où la nécessité de créer un langage à la portée
de l'humain.

André

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
On Tuesday 05 January 2016 18:58:10 jdd wrote:
> 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 :-)

ou pour créer un virus très violent...

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet 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

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet jdd 

Le 05/01/2016 19:45, andre_deb...@numericable.fr a écrit :


L'informatique ne peut exister sans l'électronique, mais pas l'inverse.




https://fr.wikipedia.org/wiki/Machine_analytique

jdd

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Dominique Asselineau 
andre_deb...@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 
> 
> Équivalent de RAZ accumulateur A avec load :
> charger l'accumulateur A (load) de la valeur  (binaire) :
> LDAA #0X  (load A value  binary)
> Code en hexadécimal :
> CE 
> Code machine compréhensible par le processeur :
> 1100 1110 
> 
> 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
--

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet 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

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
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'électronique.
> Quoique… :-DPh. 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 analogique,
toutes tensions faibles.

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Pierre TOUZEAU 


Le 04/01/2016 21:27, enae a écrit :
> 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?)
>

http://www.commentcamarche.net/contents/763-processeur
est plus simple à comprendre que le Wikipedia


Grosso modo, on repart bien de l’algèbre de Bool qui détermine la façon
de mener des opérations arithmétiques sur des valeurs codées en base 2.
Ces opérations sont "câblées" en dur dans des circuits électroniques
(des transistors à la base).
Ces circuits sont assemblés dans un même composant (un processeur) afin
de fournir des opérations plus complexes : des instructions.
Jusqu'à ce que, sous l'impulsion de cycles d'horloges réguliers, on
fournisse au processeur ainsi constitué,  des opérandes et des
opérations dans des espaces mémoire internes (des registres), qui
déroule alors son microprogramme constitué d'un jeu d’instructions fixes
(car figé dans l’électronique).
10ADDREG1, REG2# Ajoute le contenu du registre 1 au
registre 2

C'est bien évidemment un peu plus compliqué que cela, et la technologie
évoluant, des architectures nouvelles ont amélioré/complexifié cette
vision simpliste : CISC, RISC, parallélisme, processeur analogique,
gestion mémoire indexée, virtuelle, etc.

==
Écrire un compilateur (en pseudo-code), revient alors :
- écrire un compilateur selon un jeu d'instruction universelle
(pseudo-code) : lire, écrire, additionner, multiplier ...
- à coder/porter le jeu d’instruction pseudo-code dans le jeu
d’instruction (langage machine) du processeur

Var1 + Var2 ==> Load Var1,REG1 Load Var2,REG2  ADD  REG1, REG2

- à finaliser le compilateur / pseudo-code selon les dernières
spécificités du processeur
 

Bon je m'arrête là, je suis déjà trop compliqué sans doute ;-)
Pierre

-- 
Pro. Signature

Pierre Touzeau

---
Chargé de mission  Préfecture de region Basse-Normandie
SGAR, rue Daniel HUET 14038 CAEN CEDEX  +33 231 306 306
pierre.touz...@basse-normandie.pref.gouv.fr +33 608 968 574
---

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
> Le 05/01/2016 19:45, andre_deb...@numericable.fr a écrit :
> > L'informatique ne peut exister sans l'électronique, mais pas l'inverse.

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 inventer
dans ses livres) vaut le coup.

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
> andre_deb...@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 É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

Ç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é

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet jdd 

Le 05/01/2016 22:03, andre_deb...@numericable.fr a écrit :


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.



les firmware des calculatrices HP étaient fait comme ca, celui de la 
HP-41C tenait en 12Ko, avec toutes les routines de calcul


https://en.wikipedia.org/wiki/HP-41_extension_module

jdd

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet jdd 

Le 05/01/2016 22:11, andre_deb...@numericable.fr a écrit :


Cette machine informatique sans électronique n'a jamais vraiment existé.


et les grands classiques:

https://en.wikipedia.org/wiki/Turing_machine

jdd

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet andre_debian 
On Tuesday 05 January 2016 22:27:30 jdd wrote:
> Le 05/01/2016 22:11, andre_deb...@numericable.fr a écrit :
> > Cette machine informatique sans électronique n'a jamais vraiment existé.

> et les grands classiques:
> https://en.wikipedia.org/wiki/Turing_machine
> jdd

https://fr.wikipedia.org/wiki/R%C3%A8gle_%C3%A0_calcul
(vendu sur Ebay)
et
La pascaline : https://fr.wikipedia.org/wiki/Pascaline
(prix entre 100 à 400 livres)
et 
l'arithmomètre :
https://fr.wikipedia.org/wiki/Arithmom%C3%A8tre

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Haricophile 
Le Tue, 5 Jan 2016 20:27:25 +0100,
Dominique Asselineau  a écrit :

> 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

L'assembleur se compile aussi pour générer un binaire. L'assembleur
c'est bas niveau : très proche du matériel et de fait du langage
machine, on donne des instructions au processeur, pas aux fenêtres ;)
Je ne dis pas qu'on n'a jamais programmé des instructions directement en
langage machine, mais un langage comme l'assembleur est là pour éviter
ça.

Un langage comme C est suffisamment bas niveau pour permettre d'éviter
d'avoir trop recours à un langage de type assembleur, il y a aussi des
langages spécialisés pour les micro-circuits par exemple qui évitent
ça. Mais l'assembleur n'a pas disparu, on en a encore besoin pour des
usages précis. Pas pour développer une appli de compta bien
sûr. Mais peut même fabriquer un compilateur avec ;)

-- 
haricoph...@aranha.fr

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Eric Degenetais 
L'informatique actuellement déployée est électronique, mais les éléments
pour des portes logiques optroniques sont déjà faisables, et l'informatique
quantique (certes elle n'était pas à la Fnac à noël) ne sera pas
nécessairement électronique non plus.
Je me demande si on n'a pas testé aussi des processeurs chimiques par
immitation des processus nerveux...
Mais on s'égare par rapport à la question d'origine (présentation
accessible du fonctionnement des machines actuelles)
Bonne soirée
Le 5 janv. 2016 22:59,  a écrit :

> On Tuesday 05 January 2016 22:27:30 jdd wrote:
> > Le 05/01/2016 22:11, andre_deb...@numericable.fr a écrit :
> > > Cette machine informatique sans électronique n'a jamais vraiment
> existé.
>
> > et les grands classiques:
> > https://en.wikipedia.org/wiki/Turing_machine
> > jdd
>
> https://fr.wikipedia.org/wiki/R%C3%A8gle_%C3%A0_calcul
> (vendu sur Ebay)
> et
> La pascaline : https://fr.wikipedia.org/wiki/Pascaline
> (prix entre 100 à 400 livres)
> et
> l'arithmomètre :
> https://fr.wikipedia.org/wiki/Arithmom%C3%A8tre
>
>

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Eric Degenetais 
Le 5 janvier 2016 à 13:02, jdd  a écrit :

bonjour,
en ce qui me concerne, pour l'optimisation je me donne deux règles
générales:

   - optimiser un point du code parce qu'on a mesuré qu'il est lent, pas
   parce qu'on pense qu'il est lent
   - se concentrer sur les optimisations plutôt algorithmiques, en laissant
   (en général) les optimisations de niveau codage pour plus tard (moins de
   gain potentiel à ce niveau), voir en les laissant au compilateur car pour
   un certain nombre de cas il fait ça très bien...

En plus de cela, je me donne une limite:

   - se rappeler que le code sera relu par les autres humains (et aussi par
   soi un fois qu'on aura eu le temps de l'oublier), et se méfier
   d'optimisation qui l'obscurcissent et favoriserons plus tard la perte de
   temps ou les erreurs (là je me répète un peu par rapport à mon post sur les
   règles de codage). C'est bien sûr un compromis, le curseur va varier en
   fonction du niveau de pression sur les performances.

Par ailleurs, il faut se rappeler que l'optimisation sur le temps de calcul
n'est qu'une des formes optimisation, parfois il est par exemple plus
important d'économiser la mémoire ou l'espace de stockage persistant, même
au prix d'un temps de calcul plus long...

bonne fin de journée
__
Éric Dégenètais
Henix



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

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet Sylvain L. Sauvage 
Le mardi 5 janvier 2016, 13:02:49 jdd a écrit :
>[…]
> puisqu'on semble reprendre les bases, je me permet
> d'intervenir.
> 
> Un programme est composé de deux parties: une suite
> d'instructions destinées à l'ordinateur et une autre suite
> d'instructions destinées à l'utilisateur, c'est une interface
> entre l'homme et la machine. […]

  Euh… simplement : non.

  Et, à mon avis, parler de l’UI n’est pas une simplification du 
propos, du « comment ça marche un ordinateur ».
  La page de commentçamarche.net donnée par Pierre est très 
bien, voire un peu trop détaillée.

-- 
 Sylvain Sauvage

Re: Documentation complète sur la compilation de programmes

2016-01-05 Par sujet jdd 

Le 05/01/2016 11:21, Pierre TOUZEAU a écrit :


Bon je m'arrête là, je suis déjà trop compliqué sans doute ;-)


puisqu'on semble reprendre les bases, je me permet d'intervenir.

Un programme est composé de deux parties: une suite d'instructions 
destinées à l'ordinateur et une autre suite d'instructions destinées à 
l'utilisateur, c'est une interface entre l'homme et la machine.


La partie communication avec l'homme est souvent la plus longue à mettre 
au point et la moins "mécanisable", c'est là que les langages de haut 
niveau (C, Pascal...) sont le plus utile.


Mais ces parties sont exécutées à la vitesse de l'homme: très lentement! 
Aucun besoin d'optimisation en terme de vitesse, là.


Les instructions destinées à l'ordinateur sont essentiellement la 
traduction en binaire d'équations mathématiques, si les équations sont 
connues, leur programmation n'est généralement pas difficile, il existe 
même des bibliothèques ("libraries") qui font le travail. L'optimisation 
est déjà faite.


Si on doit programmer une bibliothèque soi-même, On va se retrouver 
devant deux types d'éléments de programmes: les éléments utilisés une 
fois, qu'on peut optimiser mais le gain est minime, et ceux utilisés 
souvent, "les boucles" dans lesquels un gain, même minime, devient par 
la répétition très important.


Ce sont ces boucles qu'il faut optimiser.

Un compilateur se contente d'assembler les différents morceaux pour 
qu'ils aillent bien ensemble. Il peut compter le nombre d'usages de 
chaque partie pour voir s'il est utile de l'optimiser. Surtout tous les 
ordinateurs ne sont pas faits pareil, n'ont pas la même mémoire, le même 
processeur.


Un compilateur peut créer un code optimisé pour chaque variante de 
processeur, chaque variante de matériel.


Programmer en langage machine permet d'optimiser le code pour un 
matériel particulier, pas pour un grand nombre de matériels différents.


reste qu'un compilateur ne sait pas à quoi sert le programme. Par 
exemple, si on fait un programme de contrôle de température, les 
paramètres seront différents selon qu'il s'agit d'un four ou d'un frigo.


Si vous écrivez une application nouvelle, il vous faudra donc sans doute 
optimiser à la main certains aspects, ceux qui sont inconnus du 
compilateur...


j'ai beaucoup simplifié, les spécialistes m'excuseront :-)
jdd

Re: Documentation complète sur la compilation de programmes

2016-01-04 Par sujet enae 

Bonsoir à tous,

permettez moi de vous souhaiter à tous mes meilleurs vœux pour la 
nouvelle année.


Le sujet est très intéressant, et grâce à vous, j'apprends en même temps 
beaucoup de connaissances, et je vous en remercie.


Je me posais les questions suivantes:
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?)


Cela parait tout bête, et pourtant...
de nos jours nous avons tellement l'habitude "d'appuyer sur le bouton" 
et cela fonctionne, tout démarre et est fonctionnel.
Mais il a fallu des années pour en arriver à ce stade, pour qu'une 
simple puce de silicium soit le maître d'oeuvre de tout un système 
autour duquel tourne tant de choses de nos jours.


Je vous remercie pour votre aide.

Re: Documentation complète sur la compilation de programmes

2016-01-04 Par sujet Basile Starynkevitch 

On 01/04/2016 09:27 PM, enae wrote:


Je me posais les questions suivantes:
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?


Faire un compilateur est compliqué (et l'essentiel n'est pas la 
construction de l'arbre syntaxique). Sur mon site http://gcc-melt.org/ 
la page http://gcc-melt.org/docum.html contient des références et des 
transparents décrivant ça en détails (en anglais); le compilateur GCC 
fait environ quinze millions de lignes de code (que personne ne comprend 
en totalité) et il est développé par une communauté de centaines 
d'ingénieurs (la plupart travaillant au moins à mi-temps sur GCC).


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?


Le spécifications d'un processeur sont de nos jours publiques. Chez 
Intel, la totalité de la documentation fait plusieurs milliers de pages 
(près de dix mille!). Et les ingénieurs d'Intel concoivent le processeur 
pour obéir à sa spécification. C'est un métier difficile.



comment est chargé ce code machine dans le processeur ?



Sur un PC, par son BIOS ou son UEFI. Sur une tablette par son Firmware. 
C'est du code machine "gravé en dur" dans une mémoire ROM ou Flash.


Cordialement

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

Re: Documentation complète sur la compilation de programmes

2016-01-03 Par sujet Vincent Lefevre 
On 2016-01-02 18:54:50 +0100, andre_deb...@numericable.fr wrote:
> Ce qui m'a fait tilter est que les codes de ce système d'exploitation
> sont écrits en Assembleur ASM, ce que je ne pensais pas possible
> pour un tel projet.

Le principal problème est que ce n'est quasiment pas maintenable.
Si tu veux ajouter des fonctionnalités ou corriger certains types
de bugs, ça risque de tout casser. Et toute l'optimisation peut
être perdue après un patch, alors qu'un compilateur peut refaire
tout le travail d'optimisation.

> Je voulais répondre aux "détracteurs" de l'Assembleur qui semblaient
> le condamner comme étant pratiquement plus utilisé et réservé à des
> applis processeuir 8 bits du moyen-âge, et.. la preuve que non !

L'assembleur reste bien pour certaines routines *critiques* lorsque
le compilateur n'est pas capable de bien optimiser, et à condition
de mettre les moyens pour maintenir le code, car les processeurs
évoluent...

Noter que le gain (quand il y a un gain) à programmer en assembleur
reste souvent assez faible. Il peut aussi être préférable de passer
plus de temps à réfléchir sur l'algorithme, ce qui peut permettre
d'obtenir un gain supérieur.

Ne pas oublier qu'il existe des options du compilateur qui permettent
d'alléger le code, en cassant la conformité à certaines conventions
(chose dont on ne se préoccupe pas quand on optimise en assembleur),
comme -fomit-frame-pointer pour GCC.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2016-01-03 Par sujet Vincent Lefevre 
On 2016-01-02 12:47:43 +0100, andre_deb...@numericable.fr wrote:
> On Saturday 02 January 2016 02:11:57 Vincent Lefevre wrote:
> > Tu crois tout ce que dit la pub?
> 
> Il ne s'agit pas d'une pub sur un OS, émanant d'une entreprise à profit,
> c'est une initiative formidable de développeurs sous licence Libre GPL V2, 
> permettre à de vieux PC moribonds d'utiliser un OS rapide édulcoré et 
> dépouillé, en utilisant le langage assembleur, ce qui est très original.

Rien à voir avec le profit ou la licence.

> > > L'assembleur étant le langage le plus proche du processeur 
> > > (langage machine), 
> > > il a comme première qualité la rapidité de ses programmes.
> > 
> > C'est assez simpliste comme remarque, surtout pour les x86, où
> > la rapidité, donc la façon dont on doit coder en assembleur,
> > dépend vraiment du processeur. C'est d'ailleurs pour ça que GMP
> > a du code assembleur pour chaque variante x86. Il y a d'ailleurs
> > toujours des questions ouvertes sur pourquoi tel code est plus
> > rapide qu'un autre code plus simple sur processeur Intel (les
> > processeurs AMD testés ont un comportement normal):
> 
> Tu réponds comme si KolibriOS devait être un système ultra pro.

Non, je te réponds sur la notion de simplicité.

> Il répond à un besoin, tout le monde n'a pas besoin de sécurité.

Peut-être, mais cette absence de sécurité, cela en fait un système
*plus simple*.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2016-01-03 Par sujet andre_debian 
On Saturday 02 January 2016 19:27:30 jdd wrote:
> mais je crois que la puissance des machines actuelles est telle quelle 
> est plus grande que les besoins de la plupart des utilisateurs. Fut un 
> temps où je recompilais le noyau pour gagner un peu de vitesse, je ne 
> l'ai pas fait depuis longtemps...

Distributions ultra légères : KolibriOS, Toutou-Linux... :
sauf pour redonner jeunesse à des vieux PC antédiluviens,
ou pour dépanner sa distribution principale en rade.

(avec Knoppix Live, le boot est beaucoup trop long).

André

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet andre_debian 
On Saturday 02 January 2016 02:11:57 Vincent Lefevre wrote:

> > > > Qui a écrit que l'Assembleur n'était plus beaucoup utilisé :
> > > > KolibriOS est un système d'exploitation, tout petit mais
> > > > incroyablement  optimisé Ces performances sont atteintes 
> > > > grâce à l'écriture du coeur de KolibriOS  
> > > > (noyau et pilotes) en langage * assembleur FASM * :

> > > 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.
> > 
> > Qu'en sais tu ?
> Le gain de programmer en assembleur par rapport à une compilation C
> est toujours limité. Si tu essaies de réécrire GNU Linux et toutes
> ses fonctionnalités en assembleur, tu n'arriveras jamais à tenir avec
> 8 Mo de mémoire vive.
> cf son site web. Le support hardware est très limité. Il n'y a aucune
> info concernant l'accessibilité, la localisation, le multi-utilisateur,
> la virtualisation, tout ce qui est associé à la sécurité, etc.

> > alors fais la comparaison de vitesse avec des mini distributions Linux...
> > également réputées pour leur simplicité, je dirai plutôt "dépouillé".
> > Leur site indique : "système d'exploitation tout petit mais incroyablement 
> > optimisé" (mais pas "simplicité) :

> Tu crois tout ce que dit la pub?

Il ne s'agit pas d'une pub sur un OS, émanant d'une entreprise à profit,
c'est une initiative formidable de développeurs sous licence Libre GPL V2, 
permettre à de vieux PC moribonds d'utiliser un OS rapide édulcoré et 
dépouillé, en utilisant le langage assembleur, ce qui est très original.

> > L'assembleur étant le langage le plus proche du processeur 
> > (langage machine), 
> > il a comme première qualité la rapidité de ses programmes.
> 
> C'est assez simpliste comme remarque, surtout pour les x86, où
> la rapidité, donc la façon dont on doit coder en assembleur,
> dépend vraiment du processeur. C'est d'ailleurs pour ça que GMP
> a du code assembleur pour chaque variante x86. Il y a d'ailleurs
> toujours des questions ouvertes sur pourquoi tel code est plus
> rapide qu'un autre code plus simple sur processeur Intel (les
> processeurs AMD testés ont un comportement normal):

Tu réponds comme si KolibriOS devait être un système ultra pro.
Il répond à un besoin, tout le monde n'a pas besoin de sécurité.
Maintenant, que le travail est bien lancé, comme il est Libre,
des développeurs peuvent l'améliorer.
Tu sembles nier le principe de l'Opensource :
télécharger le code source, en prendre connaissance,
l'améliorer, et le remettre à disposition.

On s'en fout des états d'âmes sur l'assembleur :
c'est une initiative originale, à découvrir, qui peut donner des idées,
il n'y a rien d'autres à dire.

André

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet jdd 

Le 02/01/2016 12:47, andre_deb...@numericable.fr a écrit :


il n'y a rien d'autres à dire.



un peu quand même, on peut aussi l'essayer.

http://kolibrios.org

déjà, la page de garde fait la promo du google of code... 2014, ensuite 
le format de l'image est prévu pour disquette, accessoire que mon 
ordinateur vieux de 5 ans ne possède plus.


Ensuite, ca marche sur cd, ca se lance sans problème sur virtualbox ou 
une machine relle, mais je n'ai pas réussi à faire une clé usb bootable, 
pas même sous windows, encore moins sous linux, ou les instructions (qui 
ne fonctionnent pas) sont pour le moins bizarres qui demandent de copier 
un secteur de boot sur /dev/sdb1 (oui sdb1, pas sdb).


une fois lancé, on a une interface pas mal mais qui semble être utile 
pour développer ou jouer...


le meilleur c'est qu'on a le net

ca ressemble donc surtout à un concept dont les concepteurs se lassent.

Pour les appareils légers, puppy linux et sa version française

http://toutoulinux.free.fr/

sont aussi rapides et un peu mieux suivis

jdd

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet andre_debian 
> Le 02/01/2016 12:47, andre_deb...@numericable.fr a écrit :
> > il n'y a rien d'autres à dire.

On Saturday 02 January 2016 13:03:41 jdd wrote:
> un peu quand même, on peut aussi l'essayer.
> http://kolibrios.org
> déjà, la page de garde fait la promo du google of code... 2014, ensuite 
> le format de l'image est prévu pour disquette, accessoire que mon 
> ordinateur vieux de 5 ans ne possède plus.
> Ensuite, ca marche sur cd, ca se lance sans problème sur virtualbox ou 
> une machine relle, mais je n'ai pas réussi à faire une clé usb bootable, 
> pas même sous windows, encore moins sous linux, ou les instructions (qui 
> ne fonctionnent pas) sont pour le moins bizarres qui demandent de copier 
> un secteur de boot sur /dev/sdb1 (oui sdb1, pas sdb).
> une fois lancé, on a une interface pas mal mais qui semble être utile 
> pour développer ou jouer...
> le meilleur c'est qu'on a le net
> ca ressemble donc surtout à un concept dont les concepteurs se lassent.
> Pour les appareils légers, puppy linux et sa version française
> http://toutoulinux.free.fr/
> sont aussi rapides et un peu mieux suivis

Le projet KolibriOS souffre de certaines erreurs et imperfections,
sans doute de jeunesse, espérons que l'équipe s'étoffera et y remédiera.

Ce qui m'a fait tilter est que les codes de ce système d'exploitation
sont écrits en Assembleur ASM, ce que je ne pensais pas possible
pour un tel projet.

Je voulais répondre aux "détracteurs" de l'Assembleur qui semblaient le 
condamner comme étant pratiquement plus utilisé et réservé à des applis 
processeuir 8 bits du moyen-âge, et.. la preuve que non !

Les vieilles méthodes peuvent renaître de leurs cendres, 
tel aussi par exemple le langage Cobol...

André

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet jdd 

Le 02/01/2016 18:54, andre_deb...@numericable.fr a écrit :


Le projet KolibriOS souffre de certaines erreurs et imperfections,
sans doute de jeunesse, espérons que l'équipe s'étoffera et y remédiera.


il date quand même de 2004 :-)



Ce qui m'a fait tilter est que les codes de ce système d'exploitation
sont écrits en Assembleur ASM, ce que je ne pensais pas possible
pour un tel projet.


c'est vrai que c'est une performance. Tout est possible, à condition de 
le vouloir




Je voulais répondre aux "détracteurs" de l'Assembleur qui semblaient le
condamner comme étant pratiquement plus utilisé et réservé à des applis
processeuir 8 bits du moyen-âge, et.. la preuve que non !


pqs sûr que ce soit une preuve, il faudrait que ce système ai du succès



Les vieilles méthodes peuvent renaître de leurs cendres,
tel aussi par exemple le langage Cobol...



un compilateur ne fait rien d'autre que d'écrire de l'assembleur :-)

j'avais cité le FORTH

https://fr.wikipedia.org/wiki/Forth_%28langage%29

http://www.forth.org/

http://www.forth.com/

parce qu'il est très facile de passer de la version de haut niveau à 
celle en assembleur


mais je crois que la puissance des machines actuelles est telle quelle 
est plus grande que les besoins de la plupart des utilisateurs. Fut un 
temps où je recompilais le noyau pour gagner un peu de vitesse, je ne 
l'ai pas fait depuis longtemps...


jdd

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet Sylvain L. Sauvage 
Le samedi 2 janvier 2016, 19:27:30 jdd a écrit :
>[…]
> j'avais cité le FORTH
>[…]
> parce qu'il est très facile de passer de la version de haut
> niveau à celle en assembleur

  À condition d’avoir un processeur à pile… (FILO, pas de Volta 
;o)

-- 
 Sylvain Sauvage

Re: Documentation complète sur la compilation de programmes

2016-01-02 Par sujet Yves Rutschle 
On Sat, Jan 02, 2016 at 06:54:50PM +0100, andre_deb...@numericable.fr wrote:
> Ce qui m'a fait tilter est que les codes de ce système d'exploitation
> sont écrits en Assembleur ASM, ce que je ne pensais pas possible
> pour un tel projet.

Bien sûr que c'est possible, par définition on peut tout
faire en assembleur. La question, c'est de savoir si c'est
efficace, si c'est le meilleur outil pour le travail, etc.

> Je voulais répondre aux "détracteurs" de l'Assembleur qui semblaient le 
> condamner comme étant pratiquement plus utilisé et réservé à des applis 
> processeuir 8 bits du moyen-âge, et.. la preuve que non !

En l'occurence, la petite taille et la performance n'ont pas
de rapport avec la technologie utilisée. C'est petit et
rapide parce que c'est largement moins complet et complexe
qu'un Linux ou Windows moderne, et s'ils avaient rempli le
même cahier des charges en C, ils seraient sans doute
arrivés au même résultat à 10% près. Dans l'embarqué, on a
des tas de systèmes d'exploitation qui prennent quelques ko
(kilo-octets, oui, moins de 100), et qui sont pourtant écris
en C: par contre, ils chargent des binaires, gèrent le
multi-tâche et les espaces mémoires de processus , et ça
s'arrête à peu près là.

J'en prendrai pour preuve le système sur 1 disquette que QNX
avait publié vers 1999: interface graphique, navigateur Web,
ça gérait tout ça dans un mouchoir de poche et à toute
vitesse. En C.

> Les vieilles méthodes peuvent renaître de leurs cendres, 
> tel aussi par exemple le langage Cobol...

Se lancer dans la programmation d'un navigateur Web en
assembleur, c'est pas de la vieille méthode, c'est de
l'inconscience. Mais bon, chacun son truc, y'en a bien qui
programment en brainfuck (on doit aussi pouvoir faire un
navigateur dans ce langage, d'ailleurs...)

Y.

Re: Documentation complète sur la compilation de programmes

2016-01-01 Par sujet Vincent Lefevre 
On 2016-01-01 23:43:48 +0100, andre_deb...@numericable.fr wrote:
> On Friday 01 January 2016 23:29:25 Vincent Lefevre wrote:
> > On 2016-01-01 22:50:37 +0100, andre_deb...@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.
> 
> Qu'en sais tu ?

Le gain de programmer en assembleur par rapport à une compilation C
est toujours limité. Si tu essaies de réécrire GNU Linux et toutes
ses fonctionnalités en assembleur, tu n'arriveras jamais à tenir avec
8 Mo de mémoire vive.

> Tu sembles vouloir saborder KolibriOS sans le connaître.
> Pourquoi KolibriOS serait-il "simple" ? :

cf son site web. Le support hardware est très limité. Il n'y a aucune
info concernant l'accessibilité, la localisation, le multi-utilisateur,
la virtualisation, tout ce qui est associé à la sécurité, etc.

Si tu as des infos, n'hésite pas à compléter:

  https://en.wikipedia.org/wiki/KolibriOS

> alors fais la comparaison de vitesse avec des mini distributions Linux...
> également réputées pour leur simplicité, je dirai plutôt "dépouillé".
> Leur site indique : "système d'exploitation tout petit mais incroyablement 
> optimisé" (mais pas "simplicité).

Tu crois tout ce que dit la pub?

> L'assembleur étant le langage le plus proche du processeur (langage machine),
> il a comme première qualité la rapidité de ses programmes.

C'est assez simpliste comme remarque, surtout pour les x86, où
la rapidité, donc la façon dont on doit coder en assembleur,
dépend vraiment du processeur. C'est d'ailleurs pour ça que GMP
a du code assembleur pour chaque variante x86. Il y a d'ailleurs
toujours des questions ouvertes sur pourquoi tel code est plus
rapide qu'un autre code plus simple sur processeur Intel (les
processeurs AMD testés ont un comportement normal):

  https://communities.intel.com/message/257079
  https://software.intel.com/en-us/forums/intel-isa-extensions/topic/533786

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2016-01-01 Par sujet andre_debian 
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.

En savoir plus, installer KolibriOS :
http://kolibrios.org/fr/

Tiens, pour 2016, ça va nous changer de Linux :-)

André

Re: Documentation complète sur la compilation de programmes

2016-01-01 Par sujet Vincent Lefevre 
On 2016-01-01 22:50:37 +0100, andre_deb...@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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2016-01-01 Par sujet andre_debian 
On Friday 01 January 2016 23:29:25 Vincent Lefevre wrote:
> On 2016-01-01 22:50:37 +0100, andre_deb...@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.

Qu'en sais tu ?
Tu sembles vouloir saborder KolibriOS sans le connaître.

Pourquoi KolibriOS serait-il "simple" ? :
alors fais la comparaison de vitesse avec des mini distributions Linux...
également réputées pour leur simplicité, je dirai plutôt "dépouillé".
Leur site indique : "système d'exploitation tout petit mais incroyablement 
optimisé" (mais pas "simplicité).

L'assembleur étant le langage le plus proche du processeur (langage machine),
il a comme première qualité la rapidité de ses programmes.

André

Re: Documentation complète sur la compilation de programmes

2015-12-31 Par sujet Sylvain L. Sauvage 
Le jeudi 31 décembre 2015, 11:31:51 jdd a écrit :
> you can also play with FORTH
> 
> https://packages.debian.org/stable/interpreters/gforth
> 
> very interesting language, pretty easy to learn, make low
> level a snap

Euh, aurais-tu déjà commencé à arroser la nouvelle année?
;oP

-- 
 Sylvain Sauvage

Re: Documentation complète sur la compilation de programmes

2015-12-31 Par sujet Basile Starynkevitch 

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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Documentation complète sur la compilation de programmes

2015-12-31 Par sujet jdd 

you can also play with FORTH

https://packages.debian.org/stable/interpreters/gforth

very interesting language, pretty easy to learn, make low level a snap

jdd

Re: Documentation complète sur la compilation de programmes

2015-12-31 Par sujet jdd 

Le 31/12/2015 13:01, Sylvain L. Sauvage a écrit :

Le jeudi 31 décembre 2015, 11:31:51 jdd a écrit :

you can also play with FORTH

https://packages.debian.org/stable/interpreters/gforth

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

Re: Documentation complète sur la compilation de programmes

2015-12-31 Par sujet 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.

Un ordre d'idée pour GMP 6.1.0:

cventin% ls **/*.asm(.) | wc -l
772
cventin% ls **/*.c(.) | wc -l
831
cventin% cat **/*.asm(.) | wc
 136918  513735 3081440
cventin% cat **/*.c(.) | wc
 145071  571333 3878004

Si on se restreint à la couche mpn:

cventin% ls **/*.asm(.) | wc -l
759
cventin% ls **/*.c(.) | wc -l
223
cventin% cat **/*.asm(.) | wc
 136016  509834 3055279
cventin% cat **/*.c(.) | wc
  39091  178321 1117751

Mais plus que la proportion par rapport au C, c'est plutôt en nombre
de lignes de code assembleur que c'est important: 136k.

> Bonne année à tous.

Bonne année,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2015-12-30 Par sujet Vincent Lefevre 
On 2015-12-29 21:42:50 +0100, andre_deb...@numericable.fr wrote:
> On Tuesday 29 December 2015 18:42:45 Vincent Lefevre wrote:
> > Il est très utilisé par GMP...
> > GMP exploite cela...
> 
> GMP = ?

https://gmplib.org/

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2015-12-29 Par sujet Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2015-12-29 Par sujet andre_debian 
On Tuesday 29 December 2015 18:42:45 Vincent Lefevre wrote:
> Il est très utilisé par GMP...
> GMP exploite cela...

GMP = ?

Re: Documentation complète sur la compilation de programmes

2015-12-28 Par sujet Basile Starynkevitch 

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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Documentation complète sur la compilation de programmes

2015-12-27 Par sujet Jacques Lav!gnotte. 
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/

Re: Documentation complète sur la compilation de programmes

2015-12-27 Par sujet enae 

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!

Re: Documentation complète sur la compilation de programmes

2015-12-27 Par sujet andre_debian 
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 tendance à 
> 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 assembleur, 
mais un langage assembleur par type de processeur. Il est nécessaire de 
connaître un minimum le fonctionnement d'un processeur pour pouvoir aborder 
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  (load register A), MOV, ADD..., STA  (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" est hautement 
recommandé (avec souvent l'option POO Programmation Orientée Objet).

André

Re: Documentation complète sur la compilation de programmes

2015-12-26 Par sujet Basile Starynkevitch 

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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Documentation complète sur la compilation de programmes

2015-12-26 Par sujet enae 

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

Re: Documentation complète sur la compilation de programmes

2015-12-26 Par sujet Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2015-12-26 Par sujet Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Documentation complète sur la compilation de programmes

2015-12-23 Par sujet Eric Degenetais 
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  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.
>