Pages : 1
#1 Le 24/06/2013, à 10:32
- jochen1727
questions sur la programmation
Bonjour je me pose une petite question a propos de la programmation, dites moi si je me trompe :
au début on programme en langage machine cad une suite de 0 et de 1 en fonction de l architecture ensuite l assembleur a permit de faire une abstraction mais c est un langage très bas niveau ou l on doit s occuper des registres et tout.... ensuite sont venus des langages tels que le fortan cobol c, mais quand on programme dans de tels langages qui offrent une abstraction plus grande ils retranscrivent en assembleur avant d être compile ? Est ce aussi le cas pour les langages récents, sont il traduit en assembleur avant d être compile?
J espéré m être bien fais comprendre n hésitez pas à me reprendre.
Hors ligne
#2 Le 24/06/2013, à 10:45
- Nasman
Re : questions sur la programmation
Au final la partie vraiment exécuté est un ensemble de 0 et de 1. Cependant tu peux avoir un langage plus évolué, voir un langage naturel qui lancera des fonctions d'un langage plus basique, lequel lancera des fonctions écrites (ou compilées) en assembleur.
En général plus le langage sera évolué et plus le code exécutable généré sera lourd - et souvent la vitesse d'exécution s'en ressentira. Malheureusement la manipulation d'un langage bas niveau est très délicate et sujette au matériel (ARM, i386, amd64...). Le lancement de ces programmes s'effectuera généralement à partir d'un OS bien défini et il faudra tenir compte de ce dernier pour des taches complexes.
Tu peux créer un programme bootable en assembleur pour aller trifouiller dans la mémoire et quelques périphériques (en utilisant les fonctions du bios) mais si tu veux le lancer depuis un OS, il faudra tenir compte de l'architecture de ce dernier (adresses mémoires, gestion de la pile etc...), faute de quoi tu auras un plantage de l'application (si l'OS est bien protégé sinon c'est le retour du BSOD ou du kernel panic).
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#3 Le 24/06/2013, à 12:52
- tiramiseb
Re : questions sur la programmation
Salut,
Dans tous les cas, c'est du code machine qui est exécuté.
L'assembleur, il en existe un différent pour chaque type de processeur : en effet, l'assembleur est très proche du matériel et directement traduit en code machine.
Le C (et autres langages compilés du genre), c'est un langage bas niveau (tu dois gérer la mémoire, etc) mais pas trop car on peut utiliser le même langage sur tous les ordinateurs. Lorsque tu compiles du C, il en ressort du code machine, adapté à telle ou telle architecture matérielle.
Le C++ est un peu plus haut niveau que le C et l'approche est la même, lorsque tu le compiles il en ressort du code machine.
Compiler, c'est transformer un programme dans un langage en code machine.
Ensuite, si on va vers les langages de plus haut niveau, on retrouve deux catégories :
- le langage interprété : tu tapes ton programme et tu l'exécutes sans le compiler : c'est l'interpréteur qui va le lire et le transformer en code machine pendant son exécution. Bien sûr, c'est plus lent.
- le langage compilé en bytecode : on est à mi-chemin entre les deux : le programme est compilé pour simplifier et accélérer l'interprétation, mais il y a une couche qui transforme ce bytecode en code machine. C'est le cas de Java et Python, par exemple. La différence entre les deux est qu'en Java tu compiles manuellement ton programme en bytecode alors qu'en Python c'est lorsque tu lances le programme qu'il est compilé avant son exécution, automatiquement. Donc à l'usage, Java ressemble plus au C alors que Python ressemble plus aux langages interprétés - tous deux sont pourtant basés sur le même principe.
Bien sûr, des langages il en existe des centaines, chacun avec ses spécificités, tu auras donc différentes approches et différentes combinaisons des approches...
Sébastien Maccagnoni - https://www.maccagnoni.eu - https://www.domotego.com
Hors ligne
#4 Le 24/06/2013, à 13:34
- grim7reaper
Re : questions sur la programmation
Compiler, c'est transformer un programme dans un langage en code machine.
Non, c’est un abus de langage.
Compiler c’est transformer un langage source en un langage cible.
Dans les faits, il est vrai que le langage cible est souvent du code machine.
Mais ce n’est pas une obligation, pour citer un truc connu : un compilateur LaTeX transforme ton code LaTeX en PDF par exemple.
Hors ligne
#5 Le 24/06/2013, à 13:36
- tiramiseb
Re : questions sur la programmation
Oui, c'est vrai, c'est un immonde raccourci 
D'ailleurs, comme je l'ai expliqué pour le java, pour lequel c'est compilé en bytecode, qui n'est pas du code machine à proprement parler.
Précision bienvenue !
Sébastien Maccagnoni - https://www.maccagnoni.eu - https://www.domotego.com
Hors ligne
#6 Le 24/06/2013, à 16:50
- jochen1727
Re : questions sur la programmation
Merci pour vos reponses 
Hors ligne
#7 Le 26/06/2013, à 13:07
- ssdg
Re : questions sur la programmation
Une petite correction: S'il est vrai que du code parfait en assembleur ira plus vite que du code parfait en C (qui ira plus vite que du code parfait en java), ce n'est pas vrai quand on code sans passer des heures à se poser la question de comment ré-écrire les listes chainés par défaut ou les fonctions malloc/free. (je pense à la comparaison de vitesse C/Java)
En général, les langages de haut niveau qui atteignent une certaine maturité mettent à disposition des optimisations à la compilation Voire à la compilation ET l’interprétation avec des choses comme JIT (just in time), l'inlining de fonctions ou de constantes, l'allocation de mémoire en masse pour éviter les appels récurrents au kernel, l'ordonnancement des instructions assembleur afin de profiter au mieux du pipeline du processeur...
Ajoutons qu'un code maintenable est souvent préférable à un code super-performant.
s'il n'y a pas de solution, c'est qu'il n'y a pas de problème... ou pas.
Hors ligne
#8 Le 26/06/2013, à 15:44
- tiramiseb
Re : questions sur la programmation
Tout à fait d'accord avec ssdg.
Par exemple en langage Python (ce que je connais le mieux), certains algorithmes sont même plus rapides en Python qu'en C, grâce aux optimisations de la machine virtuelle...
Sébastien Maccagnoni - https://www.maccagnoni.eu - https://www.domotego.com
Hors ligne
#9 Le 27/06/2013, à 03:55
- grim7reaper
Re : questions sur la programmation
En général, les langages de haut niveau qui atteignent une certaine maturité mettent à disposition des optimisations à la compilation Voire à la compilation ET l’interprétation avec des choses comme JIT (just in time), l'inlining de fonctions ou de constantes, l'allocation de mémoire en masse pour éviter les appels récurrents au kernel, l'ordonnancement des instructions assembleur afin de profiter au mieux du pipeline du processeur...
Ça, ça n’a rien de spécifique aux langages de haut-niveau.
N’importe quel compilo’ C décent va le faire.
J’ajouterai que le CPU lui même va réordonner des instructions, pas seulement le compilo’.
Enfin pour le coup de la mémoire, malloc/free l’optimise déjà (allocation par pages, puis découpage et distribution à la demande de l‘utilisateur). C’est quand même pas une implémentation naïve et supra lente (du genre un appel au noyau pour chaque allocation), mais c’est moins avancé que ce que peuvent proposer des langages de plus haut niveau, je suis d’accord.
Tout à fait d'accord avec ssdg.
Par exemple en langage Python (ce que je connais le mieux), certains algorithmes sont même plus rapides en Python qu'en C, grâce aux optimisations de la machine virtuelle...
En CPython, quasiment jamais non.
En PyPy, sur des exemples très bien choisi oui, c’est plus rapide que le C (mais de manière générale, même si c’est plus lent que du C, c’est du même ordre de grandeur donc Python n’a pas à rougir).
À la limite, si tu compiles le code Python en C++11 puis que tu compiles le C++ résultant, là oui tu peux poutrer du C.
C’est ce que fait le projet Pythran et c’est assez impressionnant (même si ça ne concerne qu’un sous-ensemble de Python)
Hors ligne
#10 Le 27/06/2013, à 13:43
- ssdg
Re : questions sur la programmation
Ça, ça n’a rien de spécifique aux langages de haut-niveau.
N’importe quel compilo’ C décent va le faire.
J’ajouterai que le CPU lui même va réordonner des instructions, pas seulement le compilo’.
Enfin pour le coup de la mémoire, malloc/free l’optimise déjà (allocation par pages, puis découpage et distribution à la demande de l‘utilisateur). C’est quand même pas une implémentation naïve et supra lente (du genre un appel au noyau pour chaque allocation), mais c’est moins avancé que ce que peuvent proposer des langages de plus haut niveau, je suis d’accord.
Après, tout dépend de ce que tu appelle un langage de haut niveau. (chez moi, tu as l'hexa qui est du langage machine, l'assembleur du bas niveau, et le C et basiquement tout ce qui n'est pas de l'assembleur du haut niveau)
Après, c'est vrai que malloc est un bon compromis, quand on ne cherche pas à optimiser son programme à mort.
tiramiseb a écrit :Tout à fait d'accord avec ssdg.
Par exemple en langage Python (ce que je connais le mieux), certains algorithmes sont même plus rapides en Python qu'en C, grâce aux optimisations de la machine virtuelle...
En CPython, quasiment jamais non.
En PyPy, sur des exemples très bien choisi oui, c’est plus rapide que le C (mais de manière générale, même si c’est plus lent que du C, c’est du même ordre de grandeur donc Python n’a pas à rougir).
À la limite, si tu compiles le code Python en C++11 puis que tu compiles le C++ résultant, là oui tu peux poutrer du C.
C’est ce que fait le projet Pythran et c’est assez impressionnant (même si ça ne concerne qu’un sous-ensemble de Python)
oui, enfin, le code généré par le premier compilateur Python -> C/C++ n'est déjà plus à la portée du dev moyen (voire non excellent)
s'il n'y a pas de solution, c'est qu'il n'y a pas de problème... ou pas.
Hors ligne
#11 Le 27/06/2013, à 14:44
- grim7reaper
Re : questions sur la programmation
grim7reaper a écrit :Ça, ça n’a rien de spécifique aux langages de haut-niveau.
N’importe quel compilo’ C décent va le faire.
J’ajouterai que le CPU lui même va réordonner des instructions, pas seulement le compilo’.
Enfin pour le coup de la mémoire, malloc/free l’optimise déjà (allocation par pages, puis découpage et distribution à la demande de l‘utilisateur). C’est quand même pas une implémentation naïve et supra lente (du genre un appel au noyau pour chaque allocation), mais c’est moins avancé que ce que peuvent proposer des langages de plus haut niveau, je suis d’accord.Après, tout dépend de ce que tu appelle un langage de haut niveau.
Oui, c’est comme la notion de typage fort/faible : c’est totalement relatif.
Tout dépend ce que tu prends comme référence.
Cela dit, le C est généralement considéré comme bas-niveau.
oui, enfin, le code généré par le premier compilateur Python -> C/C++ n'est déjà plus à la portée du dev moyen (voire non excellent)
Certes, mais le code n’est pas destiné à être lu.
Tout comme le code assembleur généré par un compilateur-optimiseur n‘est pas à la portée du premier venu.
Hors ligne