Documentation complète sur la compilation de programmes

On 2016-01-02 12:47:43 +0100, andre_debian@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 <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 2016-01-02 18:54:50 +0100, andre_debian@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 <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)

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.

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: 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} ***

Bonjour,
enae <philolilou@free.fr> 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 certaineme nt
fortement dépendant du processeur et de son architecture)
comment le processeur sait-il ce qu'il a à faire en voyant ce code m achine?
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.

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

--001a11c283086d29740528954433
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 5 janvier 2016 à 13:02, jdd <jdd@dodin.org> 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, p as
parce qu'on pense qu'il est lent
- se concentrer sur les optimisations plutôt algorithmiques, en lai ssant
(en général) les optimisations de niveau codage pour plus tard (moins de
gain potentiel à ce niveau), voir en les laissant au compilateur ca r 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 persist ant, 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

--001a11c283086d29740528954433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><br>Le 5 janvier 2016 à 13:02, jdd &lt;<a href="mai lto:jdd@dodin.org">jdd@dodin.org</a>&gt; a écrit :<br><br>bonjour,<br> en ce qui me concerne, pour l&#39;optimisation je me donne deux règles générales:<br><ul><li>optimiser un point du code parce qu&#39;on a mesuré qu&#39;il est lent, pas parce qu&#39;on pense qu&#39;il est lent</li><li>se concentrer sur les optimisations plutôt algorithmiques , en laissant (en général) les optimisations de niveau codage pou r plus tard (moins de gain potentiel à ce niveau), voir en les laissan t au compilateur car pour un certain nombre de cas il fait ça trè s bien...</li></ul><p>En plus de cela, je me donne une limite:<br></p><ul>< li>se rappeler que le code sera relu par les autres humains (et aussi par s oi un fois qu&#39;on aura eu le temps de l&#39;oublier....), et se méf ier d&#39;optimisation qui l&#39;obscurcissent et favoriserons plus tard la perte de temps ou les erreurs (là je me répète un peu par r apport à mon post sur les règles de codage). C&#39;est bien sà »r un compromis, le curseur va varier en fonction du niveau de pression s ur les performances.</li></ul><p>Par ailleurs, il faut se rappeler que l&#3 9;optimisation sur le temps de calcul n&#39;est qu&#39;une des formes optim isation, parfois il est par exemple plus important d&#39;économiser la mémoire ou l&#39;espace de stockage persistant, même au prix d&# 39;un temps de calcul plus long...<br></p><p>bonne fin de journée<br>< /p>______________<br>Éric Dégenètais<br>Henix<br><br><br><br ><a href="http://www.henix.com">http://www.henix.com</a><br><a href="ht tp://www.squashtest.org">http://www.squashtest.org</a><br></div>

--001a11c283086d29740528954433--

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 interfa ce
entre l'homme et la machine. […]

Euh… simplement : non.

Et, à mon avis, parler de l’UI n’est pas une sim plification 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

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 m achine?
comment est chargé ce code machine dans le processeur ? (j'aurai
tendance à penser à grub, mais, à la mise sous tension du processeur, à
t+1 qu'est-ce qui fait le processeur commence à faire une tâche ?)

Prenons cet exemple d'une instruction assembleur du processeur
Motorola série 6800 :

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

Exemple plus simple,
mettre à zéro l'accumulateur A :
CLRA (Clear Accumulateur A)
Code en hexadécimal :
4F
Code machine compréhensible par le processeur :
0100 1111

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

Le # exprime une valeur binaire.
Je ne suis plus sûr si c'est LDAA ou LDA...

On voit qu'il serait impossible de programmer
en hexadécimal et pire en code machine,
d'où la nécessité de créer un langage à la portà ©e
de l'humain.

André

--001a114b14ca9cde5505289951b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 5 janvier 2016 à 17:56, <andre_debian@numericable.fr> a écrit :

On voit qu'il serait impossible de programmer
en hexadécimal et pire en code machine,

Juste atrocement fastidieux...pour avoir fait les deux à petite dose i l y a
presque 25 ans, pas énormément plus qu'en assembleur (qui pour si mplifier à
plaquer des mnémoniques sur les instructions, mais en terme de verbosi té 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 pil e l'air de
rien
- spécialistes qui conçoivent les assembleurs, linkers et autr es
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 drastiq uement sa
consommation d'aspirine à utiliser les langages de niveaux supéri eurs...
bonne soirée :)

______________
Éric Dégenètais
Henix



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

--001a114b14ca9cde5505289951b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"> Le 5 janvier 2016 à 17:56, <span dir="ltr">&lt;<a href="mailto:an dre_debian@numericable.fr" target="_blank">andre_debian@numericable.fr</a >&gt;</span> a écrit :<br><blockquote class="gmail_quote" style="m argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6 tw" class="a3s" style="overflow:hidden">On voit qu&#39;il serait imposs ible de programmer<br>
en hexadécimal et pire en code machine,</div></blockquote></div><br></ div><div class="gmail_extra">Juste atrocement fastidieux...pour avoir fai t les deux à petite dose il y a presque 25 ans, pas énorméme nt plus qu&#39;en assembleur (qui pour simplifier à plaquer des mnà ©moniques sur les instructions, mais en terme de verbosité et de pro gression par sauts de puce c&#39;est du même accabit).<br><br></div><d iv class="gmail_extra">Il y a encore des gens qui manipulent ces formes d e code pour des cas de niche:<br><ul><li>hackers cherchant à caser du code dans un débordement de pile l&#39;air de rien<br></li><li>spà ©cialistes qui conçoivent les assembleurs, linkers et autres dé sassembleurs (faut bien les écrire...)</li><li>ceux qui conçoiven t les les processeurs<br></li><li>gens qui aiment &quot;le sport&quot;<br>< /li><li>j&#39;en oublie sans doute...<br></li></ul></div><div class="gmai l_extra">Ceci dit, je suis d&#39;accord, dans le cas général on l imite drastiquement sa consommation d&#39;aspirine à utiliser les lang ages de niveaux supérieurs...<br></div><div class="gmail_extra">bonn e soirée :) <br></div><div class="gmail_extra"><br clear="all"></d iv><div class="gmail_extra"><div><div class="gmail_signature"><div dir ="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"> <div><div dir="ltr"><div style="font-family:arial;font-size:small">____ __________</div><div style="font-family:arial;font-size:small"><div dir ="ltr">Éric Dégenètais<br><div>Henix<br><br><img src="ht tps://docs.google.com/uc?export=download&amp;id=0B4VkaUOkBhBIeUlWWXMxOV FHdDg&amp;revid=0B4VkaUOkBhBIcUJqdExOMUJyZkkxcFNOV1hyRmZyS3IrQ1lRPQ" heig ht="29" width="96"><br></div><div><br></div><div><img alt=""></div><d iv><a href="http://www.henix.com" target="_blank">http://www.henix.com< /a><br></div><div><a href="http://www.squashtest.org" target="_blank">h ttp://www.squashtest.org</a></div><div><br></div></div></div></div></div></ div></div></div></div></div></div></div></div></div>
</div></div>

--001a114b14ca9cde5505289951b5--