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

Bon sang, je suis un compilateur.

Je viens de scanner des milliers de lignes de code pendant que vous lisiez cette phrase. J'ai parcouru des millions de possibilités d'optimisation d'une seule de vos lignes en utilisant des centaines de techniques d'optimisation différentes basées sur une vaste quantité de recherches universitaires que vous passeriez des années à consulter. Je n'éprouverai aucune gêne, pas même un léger ick, lorsque je convertirai une boucle de trois lignes en milliers d'instructions juste pour la rendre plus rapide. Je n'ai aucune honte à aller jusqu'à l'optimisation ou à faire les tours les plus sales. Et si vous ne voulez pas que je le fasse, peut-être pour un jour ou deux, je me comporterai et ferai comme vous le souhaitez. Je peux transformer les méthodes que j'utilise quand vous le souhaitez, sans même changer une seule ligne de votre code. Je peux même vous montrer à quoi ressemblerait votre code en assembleur, sur différentes architectures de processeurs et différents systèmes d'exploitation et dans différentes conventions d'assemblage si vous le souhaitez. Oui, tout cela en quelques secondes. Parce que, vous savez, je peux ; et vous savez, vous ne pouvez pas.

P.S. Oh, au fait, tu n'utilisais pas la moitié du code que tu as écrit. Je t'ai fait une faveur et je l'ai jeté.

Answer 2

ASM a faible lisibilité y n'est pas vraiment maintenable par rapport aux langages de niveau supérieur.

De plus, il y a beaucoup de moins de développeurs ASM que pour d'autres langages plus populaires, comme le C.

De plus, si vous utilisez un langage de niveau supérieur et que de nouvelles instructions ASM sont disponibles (SSE par exemple), il vous suffit de mettre à jour votre compilateur et votre ancien code peut facilement utiliser les nouvelles instructions.

Et si le prochain processeur avait deux fois plus de registres ?

L'inverse de cette question serait : Quelle fonctionnalité les compilateurs fournissent-ils ?

Je doute que vous puissiez/voulez/deviez optimiser votre ASM mieux que gcc -O3 peut.

Answer 3

J'ai écrit des tas d'assembleurs pour les puces 6502, Z80, 6809 et 8086. J'ai arrêté de le faire dès que les compilateurs C sont devenus disponibles pour les plates-formes auxquelles je m'adressais, et je suis immédiatement devenu au moins 10x plus productif. La plupart des bons programmeurs utilisent les outils qu'ils utilisent pour des raisons rationnelles.

Answer 4

J'adore programmer en langage assembleur, mais il faut plus de code pour faire la même chose que dans un langage de haut niveau, et il existe une corrélation directe entre les lignes de code et les bogues. (Cela a été expliqué il y a des décennies dans Le mois mythique de l'homme .)

Il est possible de considérer le C comme un "assemblage de haut niveau", mais si l'on va un peu plus loin, on se retrouve dans un monde différent. En C#, vous ne réfléchissez pas à deux fois avant d'écrire ceci :

foreach (string s in listOfStrings) { /* do stuff */ }

Il s'agirait de dizaines, voire de centaines de lignes de code en assemblage, chaque programmeur qui le mettrait en œuvre adopterait une approche différente, et la personne suivante devrait s'y retrouver. Donc si vous croyez (comme beaucoup) que les programmes sont écrits principalement pour être lus par d'autres personnes, l'assembleur est moins lisible que la HLL typique.

Edit : J'ai accumulé une bibliothèque personnelle de code utilisé pour des tâches courantes, et des macros pour implémenter des structures de contrôle de type C. Mais je me suis heurté à un mur dans les années 90, lorsque les interfaces graphiques sont devenues la norme. Je passais trop de temps sur des choses qui étaient routinières.

La dernière tâche pour laquelle ASM a été essentiel était il y a quelques années, l'écriture de code pour combattre les logiciels malveillants. Il n'y avait pas d'interface utilisateur, donc toutes les parties amusantes sans la lourdeur.

Answer 5

En plus des réponses données par d'autres personnes concernant la lisibilité, la maintenabilité, un code plus court et donc moins de bogues, et une plus grande facilité d'utilisation, je vais ajouter une raison supplémentaire :

la vitesse du programme.

Oui, en assembleur, vous pouvez régler votre code à la main afin d'utiliser le moindre cycle et le rendre aussi rapide que possible. Mais qui a le temps ? Si vous écrivez un programme C pas complètement stupide, le compilateur fera un très bon travail d'optimisation pour vous. Il fera probablement au moins 95% des optimisations que vous feriez à la main, sans que vous ayez à vous soucier d'en garder la trace. Il y a définitivement une règle du 90/10 ici, où les derniers 5% d'optimisations finiront par prendre 95% de votre temps. Alors pourquoi s'embêter ?