Pourquoi les programmes ne sont-ils pas plus souvent écrits en Assembleur ?

Question

Il semble que l'opinion générale soit que la programmation en assembleur prend plus de temps et est plus difficile à programmer qu'un langage de niveau supérieur comme le C. Par conséquent, il semble être recommandé ou supposé qu'il est préférable d'écrire dans un langage de niveau supérieur pour ces raisons et pour la raison d'une meilleure portabilité.

Récemment, j'ai écrit en assembleur x86 et je me suis rendu compte que ces raisons n'étaient peut-être pas vraies, à l'exception peut-être de la portabilité. Peut-être s'agit-il plutôt d'une question de familiarité et de savoir comment bien écrire en assembleur. J'ai également remarqué que la programmation en assembleur est très différente de la programmation dans une HLL. Peut-être qu'un bon programmeur assembleur expérimenté pourrait écrire des programmes aussi facilement et aussi rapidement qu'un programmeur C expérimenté écrivant en C.

C'est peut-être parce que la programmation en assembleur est très différente de celle des HLL, et nécessite donc une réflexion, des méthodes et des moyens différents, ce qui donne l'impression qu'il est très difficile de programmer en assembleur pour ceux qui ne le connaissent pas, et lui vaut sa mauvaise réputation pour l'écriture de programmes.

Si la portabilité n'est pas un problème, alors vraiment, qu'est-ce que C a de plus qu'un bon assembleur tel que NASM ?

Edit : Juste pour signaler. Lorsque vous écrivez en assembleur, vous ne devez pas seulement écrire en codes d'instruction. Vous pouvez utiliser des macros, des procédures et vos propres conventions pour faire diverses abstractions afin de rendre les programmes plus modulaires, plus faciles à maintenir et à lire. C'est là qu'il faut savoir comment écrire correctement en assembleur.

Answer 1

Si un programme de production moyen comporte, disons, 100 000 lignes de code, et que chaque ligne représente environ 8 à 12 instructions assembleur, cela représente 1 million d'instructions assembleur.

Même si vous pouviez écrire tout cela à la main à une vitesse décente (n'oubliez pas que c'est 8 fois plus de code que vous devez écrire), que se passe-t-il si vous voulez changer certaines des fonctionnalités ? Comprendre quelque chose que vous avez écrit il y a quelques semaines à partir de ces 1 million d'instructions est un cauchemar ! Il n'y a pas de modules, pas de classes, pas de conception orientée objet, pas de frameworks, rien. Et la quantité de code similaire que vous devez écrire, même pour les choses les plus simples, est au mieux décourageante.

En outre, vous ne pouvez pas optimiser votre code aussi bien qu'un langage de haut niveau. Alors que le C, par exemple, effectue un nombre insensé d'optimisations parce que vous décrire votre intention, pas seulement votre code, en assembleur vous n'écrivez que du code, l'assembleur ne peut pas vraiment effectuer d'optimisations notables sur votre code. Ce que vous écrivez est ce que vous obtenez, et croyez-moi, vous ne pouvez pas optimiser de manière fiable 1 million d'instructions que vous corrigez et corrigez au fur et à mesure que vous les écrivez.

Answer 2

Eh bien, j'ai écrit beaucoup d'assembleur "dans le temps", et je peux vous assurer que je suis beaucoup plus productif lorsque j'écris des programmes dans un langage de haut niveau.

Answer 3

Un niveau raisonnable de compétence en assembleur est une compétence utile, surtout si vous travaillez au niveau du système ou de la programmation embarquée, non pas tant parce que vous devez écrire beaucoup d'assembleur, mais parce qu'il est parfois important de comprendre ce que la boîte est vraiment faire. Si vous n'avez pas une compréhension de bas niveau des concepts et des problèmes de l'assembleur, cela peut être très difficile.

Cependant, pour ce qui est d'écrire réellement beaucoup de code en assembleur, il y a plusieurs raisons pour lesquelles cela ne se fait pas beaucoup.

• Il n'y a tout simplement pas (ou presque) de besoin. À l'exception de quelque chose comme la toute première initialisation du système et peut-être quelques fragments d'assembleur cachés dans des fonctions ou des macros C, tout le code de très bas niveau qui aurait pu être écrit en assembleur peut être écrit en C ou C++ sans difficulté.

• Le code des langages de plus haut niveau (même C et C++) condense la fonctionnalité en beaucoup moins de lignes, et de nombreuses recherches montrent que le nombre de bogues est en corrélation avec le nombre de lignes du code source. C'est-à-dire que le même problème, résolu en assembleur et en C, aura plus de bogues en assembleur simplement parce qu'il est plus long. Le même argument motive le passage à des langages de plus haut niveau tels que Perl, Python, etc.

• En écrivant en assembleur, vous devez vous occuper de chaque aspect du problème, de la disposition détaillée de la mémoire, de la sélection des instructions, du choix des algorithmes, de la gestion de la pile, etc. Les langages de niveau supérieur vous épargnent tout cela, c'est pourquoi ils sont tellement plus denses en termes de LOC.

Essentiellement, tout ce qui précède est lié au niveau d'abstraction dont vous disposez en assembleur par rapport au C ou à un autre langage. L'assembleur vous oblige à faire toutes vos propres abstractions, et à les maintenir par votre propre autodiscipline, alors que n'importe quel langage de niveau moyen comme le C, et surtout les langages de plus haut niveau, vous fournissent des abstractions d'emblée, ainsi que la capacité d'en créer de nouvelles relativement facilement.

Answer 4

Lorsque vous écrivez en assembleur, vous ne devez pas écrire uniquement en codes d'instruction. Vous pouvez utiliser des macros, des procédures et vos propres conventions pour faire diverses abstractions afin de rendre les programmes plus modulaires, plus faciles à maintenir et à lire.

Donc, ce que vous dites en gros, c'est qu'avec l'utilisation habile d'un assembleur sophistiqué, vous pouvez rendre votre code ASM de plus en plus proche du C (ou de toute autre langue de bas niveau de votre propre invention), jusqu'à ce que finalement vous soyez aussi productif qu'un programmeur C.

Cela répond-il à votre question ? ;-)

Je ne dis pas ça par hasard : J'ai programmé en utilisant exactement un tel assembleur et un tel système. Encore mieux, l'assembleur pouvait cibler un processeur virtuel, et un traducteur séparé compilait la sortie de l'assembleur pour une plateforme cible. Un peu comme ce qui se passe avec LLVM's IF, mais dans ses premières formes, avant qu'il ne précède d'environ 10 ans. Il y avait donc la portabilité, plus la possibilité d'écrire des routines pour un assembleur cible spécifique lorsque cela était nécessaire pour l'efficacité.

Écrire en utilisant cet assembleur était à peu près aussi productif que le C, et par comparaison avec GCC-3 (qui existait à l'époque où j'ai été impliqué) l'assembleur/traducteur produisait un code à peu près aussi rapide et généralement plus petit. La taille était vraiment importante, et la société avait peu de programmeurs et était prête à enseigner un nouveau langage aux nouvelles recrues avant qu'elles puissent faire quelque chose d'utile. Et nous avions le soutien que les personnes qui ne connaissaient pas l'assembleur (par exemple les clients) pouvaient écrire en C et le compiler pour le même processeur virtuel, en utilisant la même convention d'appel et ainsi de suite, de sorte que l'interface était nette. C'était donc une victoire marginale.

C'était avec plusieurs années-hommes de travail dans le sac pour développer la technologie de l'assembleur, les bibliothèques, et ainsi de suite. Il est vrai qu'une grande partie de ce travail a servi à le rendre portable, mais s'il n'avait visé qu'une seule architecture, l'assembleur aurait été beaucoup plus facile à utiliser.

En résumé : vous pouvez ne pas aimer le C, mais cela ne signifie pas que l'effort d'utiliser le C est plus important que l'effort d'inventer quelque chose de mieux.

Answer 5

En tant que développeur qui passe la plupart de son temps dans le monde de la programmation embarquée, je dirais que l'assembleur est loin d'être un langage mort/obsolète. Il existe un certain niveau de codage proche du métal (par exemple, dans les pilotes) qui ne peut parfois pas être exprimé de manière aussi précise ou efficace dans un langage de plus haut niveau. Nous écrivons presque toutes nos routines d'interface matérielle en assembleur.

Ceci étant dit, ce code assembleur est enveloppé de telle sorte qu'il peut être appelé à partir du code C et est traité comme une bibliothèque. Nous n'écrivons pas l'intégralité du programme en assembleur pour plusieurs raisons. La première et la plus importante est la portabilité ; notre base de code est utilisée sur plusieurs produits qui utilisent différentes architectures et nous voulons maximiser la quantité de code qui peut être partagée entre eux. La deuxième raison est la familiarité des développeurs. En termes simples, les écoles n'enseignent plus l'assemblage comme avant, et nos développeurs sont bien plus productifs en C qu'en assemblage. De plus, nous disposons d'une grande variété d'"extras" (bibliothèques, débogueurs, outils d'analyse statique, etc.) pour notre code C qui ne sont pas disponibles pour le code en langage assembleur. ) disponibles pour notre code C qui ne sont pas disponibles pour le code en langage assembleur. Même si nous voulions écrire un programme purement en assembleur, nous ne pourrions pas le faire parce que plusieurs bibliothèques matérielles critiques ne sont disponibles que sous forme de bibliothèques C. Dans un sens, c'est le problème de la poule et de l'œuf. Les gens se détournent de l'assemblage parce qu'il n'y a pas autant de bibliothèques et d'outils de développement/débogage disponibles pour lui, mais les bibliothèques/outils n'existent pas parce qu'il n'y a pas assez de gens qui utilisent l'assemblage pour justifier l'effort de création.

En fin de compte, il y a un temps et un lieu pour pratiquement toutes les langues. Les gens utilisent ce qui leur est le plus familier et le plus productif. Il y aura probablement toujours une place dans le répertoire d'un programmeur pour l'assembleur, mais la plupart des programmeurs trouveront qu'ils peuvent écrire du code dans un langage de plus haut niveau qui est presque aussi efficace en beaucoup moins de temps.