Le langage machine c’est une suite de 0 et de 1. Assembleur n’est pas du langage machine. C’est le langage qui s’en rapproche le plus, parce qu’une simple « traduction littérale » permet de passer de l’asm au binaire, mais ce n’est pas similaire.
Pas tout à fait.
Le langage machine binaire et sa forme symbolique compréhensible par l’humain sont juste deux représentations différentes de la même chose.
A l’origine, le mot « assembleur » désigne le programme qui permet de passer de passer de la forme compréhensible par l’humain à celle compréhensible par la machine. Et le désassembleur permet de faire l’inverse. Au passage, je précise que j’ai écrit dans ma vie plusieurs compilateurs et même un assembleur.
Donc, c’est par abus de langage qu’on a utilisé le mot assembleur pour parler du langage machine et de la forme symbolique compréhensible par l’humain. Mais bon, ce n’est pas un problème puisqu’en général on se comprends.
Et puis, si on était rigoureux en informatique, on ne pourrait plus s’amuser à voir les mathématiciens et les scientifiques devenir fous 
Ah le kilo à 1024, quel bonheur pour tromper l’ennemi. Et le signe égal pour les assignations…
Ce n’est pas qu’un langage de programmation ne peut fonctionner sans langage machine, ce sont deux choses différente. L’un permet une représentation compréhensible par l’homme d’un programme, l’autre est le représentation compréhensible par le processeur de ce même programme.
Ce qui ne change rien à ce que j’ai affirmé, à savoir que votre joli programme écrit en langage évolué ne servira jamais à rien s’il n’est pas traduit en langage machine ou interprété par quelque chose qui est exécutable.
D’ailleurs, pour les langages évolués, ce que vous dites la peut se discuter (même si ce n’est pas non plus complètement faux) dans la mesure ou il s’agit plus d’une translation que d’une représentation différente. Il n’existe pas de correspondance directe entre une instruction en langage évoluée et une instruction en langage machine.
Même si on considère le concept de groupes d’instructions, il n’existe pas non plus de correspondance simple, ni une manière unique de traduire une instruction en langage évoluée vers un groupe d’instructions en langage machine. Deux compilateurs ne vont pas générer le même code et la compilation n’est que partiellement réversible (dé-compiler est très difficile).
Mais, je ne vois pas pourquoi tu réponds ça par rapport à mon commentaire… ASM est ultra performant (s’il est bien utilisé), puisqu’il représente exactement ce à quoi le processeur s’attends, il n’en reste pas moins que, lorsque l’on peut l’évider, on l’évite, parce que le gain en performance ne justifie que rarement l’énorme perte de temps, de risque d’erreur et difficulté de maintenabilité.
Programmer en langage machine n’est ni une perte de temps, ni une source d’erreur si vous utilisez ce langage à bon escient, quand son utilisation est indiquée et de la manière dont il faut le faire.
Ce qu’il faut comprendre c’est que contrairement aux idées reçues, la programmation en langage machine n’est pas obsolète et ne le sera jamais si l’on considère les usages qui sont pertinents pour ce langage.
Je doute que, comme tu le dis, beaucoup de développement se font encore en ASM. Même la part de code ASM des noyaux Linux ou Windows est minime, le reste c’est du C/C++, pareil en électronique.
Sauf que la quantité de lignes de code ne dit rien sur la pratique d’un langage. Car cela n’est ni représentatif du temps passé, ni de l’importance de ce code.
Aujourd’hui, le langage machine est utilisé pour de petites portions de code très fortement optimisées (donc qui comptent beaucoup dans la performance d’un ordinateur) ou pour utiliser certaines fonctions particulières des processeurs. Dans ce cadre, cela peut demander plus de temps d’écrire 10 lignes de code en langage machine que 5000 lignes pissées en Java.
Donc ce n’est pas en comptant les lignes de code que vous aurez une idée du nombre d’heure que les programmeurs consacrent a du langage machine.
Au passage, il n’y a pas que les noyaux et les drivers qui utilisent des portions de code en langage machine. C’est le cas de beaucoup de logiciels performants.
Et il y a bien d’autres usages, par exemple dans le déverminage de programmes. Devant un comportement aberrant et incompréhensible dans un programme dont le code est correct, il faut soupçonner un bug du compilateur. L’étude et le traçage au niveau langage machine permet de savoir rapidement ce qui se passe.
Même si c’est un cas de figure qui n’arrive pas tous les jours, j’ai rencontré le cas plus d’une fois. Et ceux qui ne pratiquent que les langages évolués seront incapables de trouver le problème.
On pourrait ajouter que la maîtrise et la compréhension du langage machine améliorent beaucoup la compréhension des programmeurs par rapport à ce qu’ils écrivent en langage évoluées. Ce qui améliore en pratique beaucoup leur capacité à écrire du code efficient.
pareil en électronique.
Pas vraiment.
Dès lors qu’il y a besoin d’un contrôle du timing au delà d’une certaine précision, on peux oublier tous les langages évolués, même le C.
Et il existe bien d’autres cas de figure. Par exemple sur les petits microcontrôleurs, la programmation en langage évoluée peut s’avérer pénible. J’ai vu plus d’un programmeur s’y casser les dents à tenter de faire ça en C. « je comprends pas, j’appelle la fonction et ça fait n’importe quoi, ça fait 3 semaines que je tourne en rond ». Bah ouais jeune padawan, t’as une pile riquiqui et c’est vraiment vite fait de l’écraser. T’aurais fait ça en langage machine, t’aurais gagné du temps… et cerise sur le gâteau, t’aurait encore des cheveux
