Pourquoi les programmes écrits en Assemblée ne sont-ils pas plus fréquents?
Il semble être courant de penser que la programmation de l'Assemblée prend plus de temps et est plus difficile à programmer qu'un langage de niveau supérieur tel que C. Il semble donc recommandé ou supposé qu'il est préférable d'écrire dans un langage de niveau supérieur pour ces raisons. et pour des raisons de meilleure portabilité.
Récemment, j’ai écrit dans x86 Assembly et je me suis rendu compte que ces raisons ne sont peut-être pas vraiment vraies, sauf peut-être la portabilité. C’est peut-être plus une question de familiarité et de savoir bien écrire l’Assemblée. J'ai aussi remarqué que la programmation dans Assembly est très différente de la programmation dans une HLL. Peut-être qu'un bon et expérimenté programmeur d'Assembly 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 d’Assemblées est très différente des HLL et nécessite donc une réflexion, des méthodes et des méthodes différentes, ce qui rend très difficile de programmer pour des inconnus et lui donne donc sa mauvaise réputation pour écrire des programmes.
Si la portabilité n’est pas un problème, qu’est-ce que C aurait sur un bon assembleur tel que NASM?
Modifier: Juste pour signaler. Lorsque vous écrivez dans Assembly, vous n'avez pas à écrire uniquement dans les codes d'instructions. Vous pouvez utiliser des macros et des procédures, ainsi que vos propres conventions, pour créer diverses abstractions afin de rendre les programmes plus modulaires, plus faciles à gérer et à lire. C’est ici que l’on sait comment écrire un bon assemblage.
ASM a mauvaise lisibilité et n'est pas vraiment maintenable par rapport aux langages de niveau supérieur.
En outre, il y a beaucoup de moins de développeurs ASM que pour les autres langages plus populaires, tels que C.
De plus, si vous utilisez un langage de niveau supérieur et de nouvelles instructions ASM deviennent disponibles (SSE par exemple), il vous suffit de mettre à jour votre compilateur et votre ancien code peut facilement utiliser les nouvelles instructions.
Que se passe-t-il si la prochaine CPU a deux fois plus de registres?
L'inverse de cette question serait: Quelles fonctionnalités les compilateurs fournissent-ils?
Je doute que vous puissiez/voulez/devriez optimiser votre ASM mieux que gcc -O3.
Hell®, 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 ligne à l'aide de centaines de techniques d'optimisation différentes basées sur une vaste quantité de recherches universitaires auxquelles vous consacriez des années. Je ne ressentirai aucune gêne, pas même une légère bêtise, lorsque je convertirai une boucle de trois lignes en milliers d'instructions uniquement pour accélérer les choses. Je n'ai aucune honte à faire de l'optimisation ou à réaliser les trucs les plus sales. Et si vous ne le voulez pas, peut-être pendant un jour ou deux, je vais me comporter et le faire 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 dans Assembly, sur différentes architectures de processeurs, différents systèmes d'exploitation et dans différentes conventions d'Assembly, si vous le souhaitez. Oui, tout en quelques secondes. Parce que, tu sais, je peux; et vous savez, vous ne pouvez pas.
P.S. Oh, au fait, vous n'utilisiez pas la moitié du code que vous avez écrit. Je vous ai rendu service et je l'ai jeté.
J'ai écrit des quantités d'assembleur 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 sont immédiatement devenus au moins 10 fois plus productifs. La plupart des bons programmeurs utilisent les outils qu'ils utilisent pour des raisons rationnelles.
J'adore programmer en langage assembleur, mais il faut plus de code pour faire la même chose que dans une langue 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 plusieurs décennies dans The Mythical Man-Month .)
Il est possible de penser que C est une "Assemblée de haut niveau", mais prenez quelques pas de plus et vous évoluerez dans un monde différent. En C #, vous n’avez pas hésité à écrire ceci:
foreach (string s in listOfStrings) { /* do stuff */ }
Cela représenterait des dizaines, voire des centaines de lignes de code dans Assembly, chaque programmeur l'implémentant adopterait une approche différente, et la prochaine personne qui se présenterait devrait le comprendre. Donc, si vous croyez (comme beaucoup le pensent) que les programmes sont écrits principalement pour être lus par d'autres personnes, Assembly est moins lisible que le HLL typique.
Edit: J'ai accumulé une bibliothèque personnelle de code utilisée pour les tâches courantes et des macros pour la mise en œuvre de structures de contrôle de type C. Mais je me suis heurté au mur dans les années 90, lorsque les interfaces graphiques sont devenues la norme. On passait trop de temps à des tâches routinières.
La dernière tâche pour laquelle ASM était essentiel était celle d'il y a quelques années: écrire du code pour lutter contre les logiciels malveillants. Pas d’interface utilisateur, c’était donc toutes les parties amusantes sans le bloat.
En plus des réponses des autres personnes concernant la lisibilité, la maintenabilité, un code plus court et donc moins de bugs, et étant beaucoup plus facile, je vais ajouter une raison supplémentaire:
vitesse du programme.
Oui, dans Assembly, vous pouvez ajuster à la main votre code pour utiliser chaque dernier cycle et le rendre aussi rapide que physiquement possible. Cependant 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. Réalisez probablement au moins 95% des optimisations que vous feriez à la main, sans que vous ayez à vous soucier de les suivre. Il existe certainement une règle 90/10 ici, selon laquelle les 5% restants d'optimisations finiront par prendre 95% de votre temps. Alors pourquoi s'embêter?
Si un programme de production moyen compte 100 000 lignes de code et que chaque ligne représente environ 8 à 12 instructions d'assembleur, vous obtiendrez 1 million d'instructions d'assembleur.
Même si vous pouviez écrire tout cela à la main à une vitesse convenable (rappelez-vous, c'est 8 fois plus de code que vous devez écrire), que se passe-t-il si vous souhaitez modifier certaines fonctionnalités? Comprendre quelque chose que vous avez écrit il y a quelques semaines sur un 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, pas de 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. Où C, par exemple, effectue un nombre fou d'optimisations parce que vous décrivez votre intention, pas seulement votre code, en assembleur vous écrivez seulement du code, l'assembleur ne peut pas vraiment effectuer d'optimisations dignes de la note 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-les au fur et à mesure que vous les écrivez.
Eh bien, j’ai écrit beaucoup d’Assembly "au bon vieux temps", et je peux vous assurer que je suis beaucoup plus productif lorsque j’écris des programmes dans un langage de haut niveau.
Un niveau raisonnable de compétence en assembleur est une compétence utile, en particulier si vous travaillez à n’importe quel type de système ou de programmation intégrée, pas tant parce que vous devez écrire autant d’assembleur, mais parce qu’il est parfois important de comprendre ce que la boîte est - vraiment faire. Si vous ne comprenez pas très bien les concepts et les problèmes d'assembleur, cela peut s'avérer très difficile.
Cependant, pour écrire beaucoup de code dans l'assembleur, il y a plusieurs raisons pour lesquelles il n'a pas fait grand chose.
Il n'y a tout simplement pas (presque) besoin. À l'exception de quelque chose comme l'initialisation très précoce du système et peut-être quelques fragments d'assembleur masqués dans des fonctions ou des macros C, tout code de très bas niveau qui aurait pu être écrit auparavant dans l'assembleur peut être écrit en C ou C++ sans aucune difficulté.
Le code dans les langages de plus haut niveau (même C et C++) condense la fonctionnalité en beaucoup moins de lignes et de nombreuses recherches ont montré que le nombre de bogues corrélé avec le nombre de lignes de code source. C'est-à-dire que le même problème, résolu dans assembleur et C, aura plus de bogues dans assembleur simplement parce que c'est plus long. Le même argument motive le passage à des langages de niveau supérieur tels que Perl, Python, etc.
En écrivant en assembleur, vous devez gérer chaque aspect du problème, qu'il s'agisse de la disposition détaillée de la mémoire, de la sélection des instructions, du choix des algorithmes, de la gestion des piles, etc. Les langages de plus haut niveau vous en éloignent, ce qui explique leur densité termes de LOC.
En gros, tout ce qui précède est lié au niveau d'abstraction disponible dans l'assembleur par rapport à C ou à un autre langage. Assembler vous oblige à créer vos propres abstractions et à les maintenir au moyen de votre propre discipline, où tout langage de niveau moyen comme le C, et en particulier les langages de niveau supérieur, vous fournit des abstractions prêtes à l'emploi, ainsi que capacité à en créer de nouveaux relativement facilement.
En tant que développeur qui passe le plus clair de son temps dans le monde de la programmation intégrée, je dirais que Assembly 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é avec autant de précision et d'efficacité dans un langage de niveau supérieur. Nous écrivons presque toutes nos routines d'interface matérielle en assembleur.
Cela étant dit, ce code d'assemblage est encapsulé de manière à pouvoir être appelé à partir de code C et traité comme une bibliothèque. Nous n'écrivons pas le programme complet en assemblée pour plusieurs raisons. Tout d’abord, c’est la portabilité; notre base de code est utilisée sur plusieurs produits utilisant différentes architectures et nous souhaitons maximiser la quantité de code pouvant être partagée entre eux. Deuxièmement, la familiarité des développeurs. En termes simples, les écoles n’enseignent pas l’Assemblée comme avant, et nos développeurs sont beaucoup plus productifs en C qu’en Assemblée. En outre, nous avons une grande variété d’extras (bibliothèques, débogueurs, outils d’analyse statique, etc.) disponibles pour notre code C qui ne sont pas disponibles pour le code en langage Assembly. Même si nous voulions écrire un programme pur-Assembly, nous ne le pourrions pas car plusieurs bibliothèques de matériel critiques ne sont disponibles que sous forme de bibliothèques C. En un sens, c'est un problème poulet/œuf. Les gens sont chassés d’Assembly parce qu’il n’ya pas autant de bibliothèques et d’outils de développement/débogage disponibles, mais les libs/tools n’existent pas car peu d’utilisateurs utilisent Assembly pour garantir l’effort de les créer.
En fin de compte, il y a un temps et un lieu pour presque 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 Assembly, mais la plupart des programmeurs s'apercevront qu'ils peuvent écrire du code dans un langage de niveau supérieur presque aussi efficace en bien moins de temps.
Lorsque vous écrivez dans Assembly, vous n'avez pas à écrire uniquement dans les codes d'instructions. Vous pouvez utiliser des macros et des procédures, ainsi que vos propres conventions, pour créer diverses abstractions afin de rendre les programmes plus modulaires, plus faciles à gérer et à lire.
Donc, ce que vous dites en gros, c’est que, avec l’utilisation habile d’un assembleur sophistiqué, vous pouvez rapprocher votre code ASM de C (ou de toute façon d’un autre langage de bas niveau de votre propre invention), jusqu’à ce que vous soyez finalement aussi productif qu'un programmeur C.
Est-ce que ça répond à votre question? ;-)
Je ne dis pas cela inutilement: j'ai programmé en utilisant exactement un tel assembleur et système. Mieux encore, l'assembleur pouvait cibler un processeur virtuel et un traducteur séparé compilait la sortie de l'assembleur pour une plate-forme cible. Un peu comme ce qui se passe avec la FI de LLVM, mais dans ses formes précoces, elle l’a précédée de 10 ans environ. Donc, il y avait la portabilité, plus la possibilité d'écrire des routines pour un assembleur cible spécifique lorsque cela était nécessaire pour plus d'efficacité.
Écrire à l'aide de cet assembleur était à peu près aussi productif que C et, comparé à GCC-3 (qui existait déjà à l'époque), l'assembleur/traducteur produisait du code à peu près aussi rapide et habituellement plus petit. La taille était vraiment importante et la société avait peu de programmeurs et était disposée à enseigner une nouvelle langue aux nouveaux employés avant qu'ils ne puissent faire quoi que ce soit d'utile. Et nous avions la sauvegarde que des personnes qui ne connaissaient pas l'assembleur (par exemple, des clients) pouvaient écrire C et le compiler pour le même processeur virtuel, en utilisant la même convention d'appel et ainsi de suite, pour qu'il s'interface parfaitement. Donc, c'était comme une victoire marginale.
C’était avec plusieurs années de travail dans le sac de développer la technologie d’assemblage, les bibliothèques, etc. Certes, une grande partie a été utilisée pour la rendre portable, si elle n’avait jamais ciblé qu’une architecture, puis l’assembleur tout en chantant et dansant qui chantait aurait été beaucoup plus facile.
En résumé: vous n’aimez peut-être pas C, mais cela ne signifie pas que l’effort d’utilisation de C est plus grand que celui de proposer quelque chose de mieux.
La même raison pour laquelle nous n'allons plus aux toilettes à l'extérieur, ou pourquoi nous ne parlons pas latin ou araméen.
La technologie arrive et rend les choses plus faciles et plus accessibles.
EDIT - pour cesser d'offenser les gens, j'ai supprimé certains mots.
L'assemblage n'est pas portable entre différents microprocesseurs.
Pourquoi? Facile.
Comparez ceci:
for (var i = 1; i <= 100; i++)
{
if (i % 3 == 0)
Console.Write("Fizz");
if (i % 5 == 0)
Console.Write("Buzz");
if (i % 3 != 0 && i % 5 != 0)
Console.Write(i);
Console.WriteLine();
}
avec
.locals init (
[0] int32 i)
L_0000: ldc.i4.1
L_0001: stloc.0
L_0002: br.s L_003b
L_0004: ldloc.0
L_0005: ldc.i4.3
L_0006: rem
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0
L_0014: ldc.i4.5
L_0015: rem
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0
L_0023: ldc.i4.3
L_0024: rem
L_0025: brfalse.s L_0032
L_0027: ldloc.0
L_0028: ldc.i4.5
L_0029: rem
L_002a: brfalse.s L_0032
L_002c: ldloc.0
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0
L_0038: ldc.i4.1
L_0039: add
L_003a: stloc.0
L_003b: ldloc.0
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret
Ils sont identiques en ce qui concerne les fonctionnalités. Le second n'est même pas un assembleur, mais un .NET IL (langage intermédiaire, similaire au bytecode de Java). La deuxième compilation transforme l’IL en code natif (c’est-à-dire presque l’assembleur), ce qui le rend encore plus cryptique.
J'imagine qu'ASM sur même x86 (_64) est logique dans les cas où vous gagnez beaucoup en utilisant des instructions difficiles à optimiser pour un compilateur. Par exemple, x264 utilise beaucoup d’asm pour son encodage, et les gains de vitesse sont énormes.
Idem la plupart de ce que d'autres ont dit.
Dans le bon vieux temps avant que C n'ait été inventé, lorsque les seuls langages de haut niveau étaient des choses comme COBOL et FORTRAN, il y avait beaucoup de choses qu'il n'était tout simplement pas possible de faire sans recourir à l'assembleur. C'était le seul moyen d'obtenir toute la flexibilité, d'accéder à tous les appareils, etc. Mais C a été inventé et presque tout ce qui était possible dans Assembly était possible dans C. J'ai très peu écrit Assembly depuis ensuite.
Cela dit, je pense que c’est un exercice très utile pour les nouveaux programmeurs d’apprendre à écrire en assembleur. Non pas parce qu'ils l'utilisent beaucoup, mais parce que vous comprenez alors ce qui se passe réellement à l'intérieur de l'ordinateur. J'ai vu beaucoup d'erreurs de programmation et de code inefficace de la part de programmeurs qui n'ont clairement aucune idée de ce qui se passe réellement avec les bits, les octets et les registres.
L’une des premières découvertes (vous le trouverez dans le Mythical Man-Month de Brooks, tiré de l’expérience des années 1960) est que les gens étaient plus ou moins aussi productifs dans une langue, dans une autre. lignes de code déboguées par jour. Cela n’est évidemment pas universellement vrai et peut se rompre lorsque poussé trop loin, mais c’était généralement vrai pour les langages de haut niveau de l’époque de Brooks.
Par conséquent, le moyen le plus rapide d’obtenir de la productivité serait d’utiliser des langages où une seule ligne de code ferait plus, et cela fonctionne effectivement, du moins pour les langages de complexité tels que FORTRAN et COBOL, ou pour donner un exemple plus moderne C.
La portabilité est toujours un problème - si ce n'est maintenant, du moins éventuellement. Chaque année, l’industrie de la programmation consacre des milliards de dollars au portage de vieux logiciels qui, au moment de sa rédaction, n’avaient "évidemment" aucun problème de portabilité.
Il y a eu un cercle vicieux lorsque Assembly est devenu moins banal: à mesure que les langages de niveau supérieur évoluaient, les jeux d’instructions de langage Assembly étaient construits moins pour la commodité des programmeurs et davantage pour ceux des compilateurs.
Donc, de manière réaliste, il peut être très difficile de prendre les bonnes décisions, par exemple, sur les registres à utiliser ou sur les instructions légèrement plus efficaces. Les compilateurs peuvent utiliser des méthodes heuristiques pour déterminer les compromis susceptibles de générer les meilleurs résultats. Nous pouvons probablement réfléchir à de plus petits problèmes et trouver des optimisations locales qui pourraient surpasser nos compilateurs maintenant très sophistiqués, mais il y a de fortes chances que dans la moyenne des cas, un bon compilateur fera un meilleur travail du premier coup qu'un bon programmeur. Finalement, comme John Henry, nous pourrions battre la machine, mais nous pourrions nous épuiser sérieusement pour y arriver.
Nos problèmes sont également très différents maintenant. En 1986, j’essayais de trouver un moyen d’accélérer un peu la vitesse des petits programmes qui impliquaient de placer quelques centaines de pixels à l’écran; Je voulais que l'animation soit moins saccadée. Un cas juste pour la langue de l'Assemblée. Maintenant, j'essaie de comprendre comment représenter les abstractions autour du langage contractuel et de la politique d'agent contractuel pour les prêts hypothécaires, et je préfère lire quelque chose qui ressemble beaucoup au langage parlé par les gens d'affaires. Contrairement aux macros LISP, les macros d'assemblage n'appliquent pas beaucoup de règles. Même si vous pouvez obtenir quelque chose d'assez proche d'un DSL dans un bon assembleur, il sera sujet à toutes sortes de bizarreries qui ont gagné ". ne me cause pas de problèmes si j’écris le même code en Ruby, Boo, LISP, C # ou même F #.
Si vos problèmes sont faciles à exprimer dans un langage de montage efficace, vous aurez plus de pouvoir.
Je programme en Assemblée depuis environ un mois. J'écris souvent un morceau de code en C et le compile ensuite à Assembly pour m'aider. Je n'utilise peut-être pas toute la puissance d'optimisation du compilateur C, mais il semble que ma source C asm inclut des opérations inutiles. Je commence donc à voir que le discours d’un bon compilateur C surpassant un bon codeur Assembly n’est pas toujours vrai.
Quoi qu'il en soit, mes programmes d'assemblage sont tellement rapides. Et plus j'utilise Assembly, moins il me faut de temps pour écrire mon code car ce n'est vraiment pas si difficile. De plus, le commentaire sur la piètre lisibilité de l’Assemblée n’est pas vrai. Si vous étiquetez correctement vos programmes et faites des commentaires lorsque des détails supplémentaires sont nécessaires, vous devriez être prêt. En fait, l’assemblage est plus clair pour le programmeur car il voit ce qui se passe au niveau du processeur. Je ne connais pas les autres programmeurs mais j'aime bien savoir ce qui se passe plutôt que d'être dans une sorte de boîte noire.
Cela dit, le véritable avantage des compilateurs est qu’un compilateur peut comprendre les modèles et les relations, puis les coder automatiquement aux emplacements appropriés de la source. Un exemple populaire est les fonctions virtuelles en C++ qui nécessitent que le compilateur mappe de manière optimale les pointeurs de fonction. Cependant, un compilateur est limité à ce que le fabricant du compilateur lui permet de faire. Cela amène parfois les programmeurs à recourir à des choses bizarres avec leur code, en ajoutant du temps de codage, alors qu'ils auraient pu être réalisés de manière triviale avec Assembly.
Personnellement, je pense que le marché supporte fortement les langages de haut niveau. Si la langue de l’Assemblée était la seule langue qui existe aujourd’hui, il y aurait environ 70% de programmation en moins et qui sait où notre monde serait, probablement dans les années 90. Les langues de niveau supérieur intéressent un plus grand nombre de personnes. Cela permet à un plus grand nombre de programmeurs de créer l'infrastructure nécessaire de notre monde. Les pays en développement comme la Chine et l’Inde tirent un grand profit des langues telles que Java. Ces pays développeront rapidement leur infrastructure informatique et les personnes deviendront plus interconnectées. Donc, ce que je veux dire, c'est que les langages de haut niveau sont populaires non pas parce qu'ils produisent un code supérieur, mais parce qu'ils aident à répondre à la demande sur les marchés mondiaux.
Je suis sûr qu'il y a beaucoup de raisons, mais deux raisons rapides que je peux penser sont
- Le code d'assemblage est nettement plus difficile à lire (je suis certain que c'est plus long à écrire aussi)
- Lorsque vous avez une énorme équipe de développeurs travaillant sur un produit, il est utile de diviser votre code en blocs logiques et de le protéger par des interfaces.
Je ne peux que dire pourquoi, personnellement, je n'écris pas plus souvent de programmes dans Assembly, et la raison principale est que c'est plus fastidieux à faire. De plus, je pense que c'est plus facile de se tromper légèrement sans s'en rendre compte immédiatement. Par exemple, vous pouvez changer la façon dont vous utilisez un registre dans une routine, mais oublier de changer cela au même endroit. Ça va se réunir bien et vous ne remarquerez peut-être que beaucoup plus tard.
Cela dit, je pense qu’il existe encore des utilisations valables pour Assembly. Par exemple, j'ai un certain nombre de routines d'assemblage assez optimisées pour le traitement de grandes quantités de données, en utilisant SIMD et en suivant l'approche paranoïaque "chaque bit est sacré" [citer V.Stob]. (Notez cependant que les implémentations d'assemblage naïfs sont souvent bien pires que ce qu'un compilateur générerait pour vous.)
J'apprends actuellement l'assemblage dans comp org, et bien que ce soit intéressant, il est également très inefficace d'écrire. Vous devez garder beaucoup plus de détails dans votre tête pour que les choses fonctionnent, et c'est aussi plus lent pour écrire les mêmes choses. . Par exemple, une simple boucle de 6 lignes pour C++ peut être égale à 18 lignes ou plus de Assembly.
Personnellement, c'est amusant d'apprendre le fonctionnement du matériel et cela me permet de mieux comprendre le fonctionnement de l'informatique.
Les gens semblent oublier qu'il y a aussi l'inverse.
Pourquoi écrivez-vous dans Assembler en premier lieu? Pourquoi ne pas écrire le programme dans une langue vraiment de bas niveau?
Au lieu de
mov eax, 0x123
add eax, 0x456
Push eax
call printInt
vous pourriez tout aussi bien écrire
B823010000
0556040000
50
FF15.....
Cela a donc plusieurs avantages, vous connaissez la taille exacte de votre programme, vous pouvez réutiliser la valeur des instructions en tant qu'entrée pour d'autres instructions et vous n'avez même pas besoin d'un assembleur pour l'écrire, vous pouvez utiliser n'importe quel paramètre. éditeur de texte...
Et la raison pour laquelle vous préférez toujours Assembler à ce sujet, est la raison pour laquelle d'autres personnes préfèrent C ...
C est un assembleur de macro! Et c'est le meilleur!
Il peut faire presque tout ce que Assembly peut faire, il peut être portable et dans la plupart des rares cas où il ne peut pas faire quelque chose, vous pouvez toujours utiliser le code Assembly intégré. Cela ne laisse qu'une petite fraction des programmes que vous devez absolument écrire dans Assembly et rien que Assembly.
Et les abstractions de niveau supérieur et la portabilité rendent l’écriture du logiciel système en C plus rentable pour la plupart des gens. Et même si vous n’avez pas besoin de la portabilité maintenant, si vous investissez beaucoup de temps et d’argent dans la rédaction d’un programme, vous ne voudrez peut-être pas vous limiter dans ce que vous pourrez utiliser à l'avenir.
Ce que C a sur un bon assembleur de macro est le langage C. Vérification de type. Boucle construit. Gestion automatique de la pile. Gestion de variable automatique (presque). Les techniques de mémoire dynamique chez l'assembleur sont une douleur énorme dans le culot. Faire une liste chaînée correctement est tout simplement effrayant par rapport à C ou mieux encore listez foo.insert (). Et le débogage - eh bien, il n’ya pas de concours sur ce qui est plus facile à déboguer. Les HLL gagnent haut la main là-bas.
J'ai codé près de la moitié de ma carrière en assembleur, ce qui me permet de penser facilement à assmebler. cela m'aide à voir ce que fait le compilateur C, ce qui m'aide encore à écrire du code qu'il peut gérer efficacement. Une routine bien pensée écrite en C peut être écrite pour produire exactement ce que vous voulez dans un assembleur avec un peu de travail - et c'est portable! J'ai déjà dû réécrire quelques anciennes routines asm en C pour des raisons de plate-forme croisée et ce n'est pas amusant.
Non, je vais rester avec C et traiter le léger ralentissement occasionnel de la performance par rapport au temps de productivité que je gagne avec HLL.
Parce que c'est toujours comme ça: le temps passe et les bonnes choses disparaissent aussi :(
Mais lorsque vous écrivez du code asm, le sentiment est totalement différent de celui obtenu lorsque vous codez des langs de haut niveau, même si vous savez que c'est beaucoup moins productif. C'est comme si vous étiez un peintre: vous êtes libre de dessiner ce que vous aimez comme vous le souhaitez, sans aucune restriction (enfin, uniquement par les fonctions du processeur) ... C'est pourquoi j'aime ça. Dommage que cette langue s'en aille. Mais tant que quelqu'un s'en souviendra encore et le codera, il ne mourra jamais!
$$$
Une entreprise embauche un développeur pour transformer le code en $$$. Plus le code tile peut être produit rapidement, plus l'entreprise peut le transformer rapidement en $$$.
Les langages de niveau supérieur sont généralement plus aptes à produire de plus gros volumes de code utile. Cela ne veut pas dire que l'Assemblée n'a pas sa place, car il y a des moments et des endroits où rien ne fera.
L’avantage des HLL est encore plus grand lorsque vous comparez Assembly à un langage de niveau supérieur à C, par exemple. Java ou Python ou Ruby. Par exemple, ces langues ont un ramasse-miettes: vous n'avez pas à vous soucier du moment où vous allez libérer une partie de la mémoire, ni des fuites de mémoire ou des bugs dus à une libération trop précoce.
Comme d'autres l'ont déjà mentionné, la raison d'être de tout outil réside dans son efficacité. Comme les HLL peuvent accomplir les mêmes tâches que plusieurs lignes de code asm, il est naturel que Assembly soit remplacé par d'autres langues. Et pour le violon proche du matériel - il y a un assemblage intégré en C et d’autres variantes selon la langue. Dr. Paul Carter dans dit dans le langage d'assemblage de PC
"... une meilleure compréhension du fonctionnement réel des ordinateurs à un niveau inférieur à celui des langages de programmation tels que Pascal. En approfondissant sa compréhension du fonctionnement des ordinateurs, le lecteur peut souvent être beaucoup plus productif en développant des logiciels dans des langages de niveau supérieur tels que C et C++. Apprendre à programmer en langage Assembly est un excellent moyen d’atteindre cet objectif. "
Nous avons introduit à l'Assemblée dans mes cours au collège. Ça va aider à clarifier les concepts. Cependant, je doute que l’un d’entre nous écrit 90% du code dans Assembly. Quelle est la pertinence des connaissances approfondies de l'Assemblée aujourd'hui?