it-swarm.com.de

Warum werden in Assembly keine Programme mehr geschrieben?

Es scheint eine gängige Meinung zu sein, dass die Assembly-Programmierung länger dauert und schwieriger zu programmieren ist als eine höhere Programmiersprache wie C. Aus diesen Gründen scheint es daher empfehlenswert oder anzunehmen, dass es besser ist, in einer höheren Programmiersprache zu schreiben und aus Gründen der besseren Portabilität.

Kürzlich habe ich in x86 Assembly geschrieben und es ist mir aufgefallen, dass diese Gründe vielleicht nicht wirklich zutreffen, außer vielleicht Portabilität. Vielleicht ist es eher eine Frage der Vertrautheit und des Wissens, wie man eine Versammlung gut schreibt. Mir ist auch aufgefallen, dass die Programmierung in Assembly ganz anders ist als die Programmierung in einer HLL. Vielleicht kann ein guter und erfahrener Assembly-Programmierer Programme genauso einfach und schnell schreiben wie ein erfahrener C-Programmierer, der in C schreibt.

Vielleicht liegt es daran, dass die Assembly-Programmierung ganz anders ist als HLLs und daher andere Denkweisen, Methoden und Methoden erfordert, was es sehr umständlich erscheinen lässt, sich auf Unbekannte einzulassen, und ihm daher seinen schlechten Namen beim Schreiben von Programmen gibt.

Wenn Portabilität kein Problem ist, was hätte C dann wirklich gegen einen guten Assembler wie NASM?

Bearbeiten: Nur um darauf hinzuweisen. Wenn Sie in Assembly schreiben, müssen Sie nicht nur in Anweisungscodes schreiben. Sie können Makros und Prozeduren sowie Ihre eigenen Konventionen verwenden, um verschiedene Abstraktionen zu erstellen, damit Programme modularer, wartbarer und besser lesbar werden. Hier kommt es darauf an, sich mit dem Schreiben einer guten Versammlung vertraut zu machen.

216
mudge

ASM hat schlechte Lesbarkeit und ist nicht wirklich wartbar im Vergleich zu höheren Sprachen.

Es gibt auch viele weniger ASM-Entwickler als für andere populärere Sprachen, wie z. B. C.

Wenn Sie eine höhere Sprache verwenden und neue ASM-Anweisungen werden verfügbar (z. B. SSE), müssen Sie nur Ihren Compiler aktualisieren, und Ihr alter Code kann die neuen Anweisungen problemlos verwenden.

Was ist, wenn die nächste CPU doppelt so viele Register hat?

Die Umkehrung dieser Frage wäre: Welche Funktionalität bieten Compiler?

Ich bezweifle, dass Sie Ihr ASM besser optimieren können/wollen/sollten als gcc -O3 kann.

332
Ben S

Verdammt, ich bin ein Compiler.

Ich habe gerade Tausende von Codezeilen gescannt, als Sie diesen Satz gelesen haben. Ich habe durch Millionen von Möglichkeiten geblättert, eine einzelne Zeile von Ihnen mit Hunderten von verschiedenen Optimierungstechniken zu optimieren, basierend auf einer riesigen Menge an akademischer Forschung, an der Sie jahrelang arbeiten würden. Es wird mir nicht peinlich sein, wenn ich eine dreizeilige Schleife in Tausende von Anweisungen umwandle, um sie schneller zu machen. Ich schäme mich nicht, viel zu optimieren oder die schmutzigsten Tricks zu machen. Und wenn du es nicht willst, vielleicht für ein oder zwei Tage, benehme ich mich und mache es so, wie du willst. Ich kann die Methoden, die ich verwende, jederzeit ändern, ohne auch nur eine einzige Codezeile zu ändern. Ich kann Ihnen sogar zeigen, wie Ihr Code in Assembly, auf verschiedenen Prozessorarchitekturen und verschiedenen Betriebssystemen und in verschiedenen Assemblykonventionen aussehen würde, wenn Sie möchten. Ja, alles in Sekunden. Weil ich es kann. und du weißt, du kannst nicht.

P.S. Übrigens haben Sie nicht die Hälfte des Codes verwendet, den Sie geschrieben haben. Ich habe dir einen Gefallen getan und ihn weggeworfen.

1931
Sedat Kapanoglu

Ich habe viele Assembler für die Chips 6502, Z80, 6809 und 8086 geschrieben. Ich hörte damit auf, sobald C-Compiler für die Plattformen verfügbar wurden, die ich ansprach, und wurde sofort mindestens 10-mal produktiver. Die meisten guten Programmierer verwenden die von ihnen verwendeten Tools aus rationalen Gründen.

99
anon

Ich liebe es, in Assembler zu programmieren, aber es braucht mehr Code, um das Gleiche wie in einer Hochsprache zu tun, und es besteht eine direkte Korrelation zwischen Codezeilen und Fehlern. (Dies wurde vor Jahrzehnten in The Mythical Man-Month erklärt.)

Es ist möglich, sich C als „Versammlung auf hoher Ebene“ vorzustellen, aber wenn Sie ein paar Schritte darüber hinausgehen, befinden Sie sich in einer anderen Welt. In C # denken Sie nicht zweimal darüber nach, Folgendes zu schreiben:

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

Das wären Dutzende, vielleicht Hunderte von Codezeilen in Assembly. Jeder Programmierer, der es implementiert, würde einen anderen Ansatz verfolgen, und die nächste Person würde es herausfinden müssen. Wenn Sie also glauben (wie viele), dass Programme in erster Linie für andere Personen geschrieben wurden, ist Assembly weniger lesbar als die typische HLL.

Edit: Ich habe eine persönliche Codebibliothek für allgemeine Aufgaben und Makros zum Implementieren von C-ähnlichen Kontrollstrukturen angelegt. Aber ich bin in den 90ern an die Wand geraten, als GUIs zur Norm wurden. Es wurde zu viel Zeit für Routine aufgewendet.

Die letzte Aufgabe, die ich hatte, bei der ASM eine wesentliche Rolle spielte, war vor einigen Jahren das Schreiben von Code zur Bekämpfung von Malware. Keine Benutzeroberfläche, so war es alle lustigen Teile ohne Aufblähen.

72
egrunin

Zusätzlich zu den Antworten anderer Leute auf Fragen der Lesbarkeit, Wartbarkeit, des kürzeren Codes und damit weniger Bugs und der Vereinfachung füge ich einen weiteren Grund hinzu:

programmgeschwindigkeit.

Ja, in Assembly können Sie Ihren Code von Hand optimieren, um jeden letzten Zyklus zu nutzen und ihn so schnell wie möglich zu machen. Aber wer hat die Zeit? Wenn Sie ein nicht ganz dummes C-Programm schreiben, wird der Compiler wirklich gute Optimierungsarbeit für Sie leisten. Nehmen Sie wahrscheinlich mindestens 95% der Optimierungen von Hand vor, ohne dass Sie sich darum sorgen müssen, dass Sie den Überblick behalten. Es gibt definitiv eine 90/10-Regel, bei der die letzten 5% der Optimierungen 95% Ihrer Zeit in Anspruch nehmen. Wieso sich die Mühe machen?

15
Brian Postow

Wenn ein durchschnittliches Produktionsprogramm beispielsweise 100.000 Codezeilen enthält und jede Zeile etwa 8-12 Assembler-Anweisungen enthält, entspricht dies 1 Million Assembler-Anweisungen.

Selbst wenn Sie dies alles mit einer anständigen Geschwindigkeit von Hand schreiben könnten (denken Sie daran, dass Sie 8-mal mehr Code schreiben müssen), was passiert, wenn Sie einige der Funktionen ändern möchten? Es ist ein Albtraum, zu verstehen, was Sie vor ein paar Wochen aus diesen 1 Million Anweisungen geschrieben haben! Es gibt keine Module, keine Klassen, kein objektorientiertes Design, keine Frameworks, kein Nichts. Und die Menge an ähnlich aussehendem Code, die Sie selbst für die einfachsten Dinge schreiben müssen, ist bestenfalls entmutigend.

Außerdem können Sie Ihren Code nicht annähernd so gut optimieren wie eine Hochsprache. Wo C zum Beispiel eine verrückte Anzahl von Optimierungen durchführt, weil Sie beschreiben Ihre Absicht, nicht nur Ihren Code, in Assembler schreiben Sie nur Code, der Assembler kann keine wirklich nennenswerten Optimierungen an Ihrem Code durchführen . Was Sie schreiben, ist das, was Sie bekommen, und vertrauen Sie mir, Sie können 1 Million Anweisungen, die Sie während des Schreibens patchen und patchen, nicht zuverlässig optimieren.

13
Blindy

Nun, ich habe "in den alten Tagen" viel Assembly geschrieben, und ich kann Ihnen versichern, dass ich viel produktiver bin, wenn ich Programme in einer höheren Programmiersprache schreibe.

8
Maurice Perry

Ein angemessenes Maß an Assembler-Kompetenz ist eine nützliche Fähigkeit, insbesondere wenn Sie auf einer beliebigen Systemebene oder mit eingebetteter Programmierung arbeiten, nicht so sehr, weil Sie so viel Assembler schreiben müssen, sondern weil es manchmal wichtig ist, zu verstehen, was die Box ist. wirklich tun. Wenn Sie keine grundlegenden Kenntnisse über Assembler-Konzepte und -Probleme haben, kann dies sehr schwierig sein.

Es gibt jedoch mehrere Gründe, warum nicht viel getan wird, um tatsächlich viel Code in Assembler zu schreiben.

  • Es gibt einfach keine (fast) Notwendigkeit. Mit Ausnahme der sehr frühen Systeminitialisierung und einiger Assembler-Fragmente, die in C-Funktionen oder Makros versteckt sind, kann jeder sehr einfache Code, der einmal in Assembler geschrieben wurde, problemlos in C oder C++ geschrieben werden.

  • Code in höheren Programmiersprachen (sogar C und C++) komprimiert die Funktionalität in weitaus weniger Zeilen, und es gibt umfangreiche Untersuchungen, die belegen, dass die Anzahl der Fehler mit der Anzahl der Quellcodezeilen korreliert. Dh, dasselbe Problem, das in Assembler und C gelöst wurde, wird mehr Fehler in Assembler haben, nur weil es länger ist. Das gleiche Argument motiviert den Wechsel zu höheren Sprachen wie Perl, Python usw.

  • Wenn Sie in Assembler schreiben, müssen Sie sich mit jedem einzelnen Aspekt des Problems befassen, von detailliertem Speicherlayout, Anweisungsauswahl, Algorithmusauswahl, Stapelverwaltung usw. Höhere Sprachen nehmen Ihnen all dies weg, weshalb sie so viel dichter sind Bedingungen von LOC.

Im Wesentlichen hängen alle oben genannten Punkte mit der Abstraktionsebene zusammen, die Ihnen in Assembler im Vergleich zu C oder einer anderen Sprache zur Verfügung steht. Assembler zwingt Sie dazu, alle Ihre eigenen Abstraktionen zu erstellen und diese durch Ihre eigene Selbstdisziplin beizubehalten, wobei jede Sprache mittlerer Stufe wie C und insbesondere Sprachen höherer Stufen Ihnen sowohl Abstraktionen von der Stange als auch Abstraktionen von der Stange bietet Fähigkeit, relativ einfach neue zu erstellen.

6
Dale Hagglund

Als Entwickler, der den größten Teil seiner Zeit in der Welt der eingebetteten Programmierung verbringt, würde ich argumentieren, dass Assembly weit entfernt von einer toten/veralteten Sprache ist. Es gibt eine gewisse metallnahe Codierungsebene (z. B. in Treibern), die manchmal in einer höheren Sprache nicht so genau oder effizient ausgedrückt werden kann. Wir schreiben fast alle unsere Hardware-Schnittstellenroutinen in Assembler.

Davon abgesehen wird dieser Assembly-Code so verpackt, dass er aus C-Code aufgerufen werden kann und wie eine Bibliothek behandelt wird. Wir schreiben aus vielen Gründen nicht das gesamte Programm in Assembly. In erster Linie ist Portabilität; Unsere Codebasis wird für mehrere Produkte verwendet, die unterschiedliche Architekturen verwenden, und wir möchten die Codemenge maximieren, die zwischen ihnen gemeinsam genutzt werden kann. Zweitens ist die Vertrautheit der Entwickler. Einfach ausgedrückt, die Schulen unterrichten Assembly nicht mehr so ​​wie früher, und unsere Entwickler sind in C weitaus produktiver als in Assembly. Außerdem bieten wir eine Vielzahl von "Extras" (z. B. Bibliotheken, Debugger, statische Analysetools usw.) für unseren C-Code an, die für Assembler-Code nicht verfügbar sind. Selbst wenn wir ein reines Assembly-Programm schreiben wollten, wären wir nicht in der Lage, da mehrere wichtige Hardware-Bibliotheken nur als C-Bibliotheken verfügbar sind. In gewisser Hinsicht ist es ein Huhn/Ei-Problem. Leute werden von Assembly vertrieben, weil nicht so viele Bibliotheken und Entwicklungs-/Debug-Tools dafür verfügbar sind, aber die Bibliotheken/Tools existieren nicht, weil nicht genügend Leute Assembly verwenden, um den Aufwand zu rechtfertigen, sie zu erstellen.

Am Ende gibt es für fast jede Sprache eine Zeit und einen Ort. Die Menschen nutzen das, was sie am besten kennen und können. Es wird wahrscheinlich immer einen Platz im Programmiererrepertoire für Assembler geben, aber die meisten Programmierer werden feststellen, dass sie Code in einer höheren Sprache schreiben können, die in viel kürzerer Zeit fast genauso effizient ist.

6
bta

Wenn Sie in Assembly schreiben, müssen Sie nicht nur in Anweisungscodes schreiben. Sie können Makros und Prozeduren sowie Ihre eigenen Konventionen verwenden, um verschiedene Abstraktionen zu erstellen, damit Programme modularer, wartbarer und besser lesbar werden.

Sie sagen also im Grunde genommen, dass Sie mit einem erfahrenen Assembler Ihren ASM-Code immer näher an C (oder an eine andere einfache Sprache Ihrer eigenen Erfindung) heranführen können, bis Sie es schließlich auch sind so produktiv wie ein C-Programmierer.

Beantwortet das deine Frage? ;-)

Ich sage das nicht untätig: Ich habe mit genau einem solchen Assembler und System programmiert. Noch besser ist, dass der Assembler auf einen virtuellen Prozessor abzielen kann und ein separater Übersetzer die Ausgabe des Assemblers für eine Zielplattform kompiliert. Ähnlich wie bei LLVMs IF, aber in seiner frühen Form um etwa 10 Jahre vor der Datierung. Es gab also Portabilität und die Möglichkeit, Routinen für einen bestimmten Zielassembler zu schreiben, wenn dies für die Effizienz erforderlich ist.

Das Schreiben mit diesem Assembler war ungefähr so ​​produktiv wie C, und im Vergleich zu GCC-3 (das zu der Zeit, als ich involviert war) produzierte der Assembler/Übersetzer Code, der ungefähr so ​​schnell und normalerweise kleiner war. Die Größe war wirklich wichtig, und das Unternehmen hatte nur wenige Programmierer und war bereit, neuen Mitarbeitern eine neue Sprache beizubringen, bevor sie etwas Nützliches tun konnten. Und wir hatten die Sicherheit, dass Leute, die den Assembler nicht kannten (z. B. Kunden), C schreiben und es für denselben virtuellen Prozessor kompilieren konnten, wobei dieselbe Aufrufkonvention usw. verwendet wurde, so dass die Schnittstelle ordnungsgemäß funktionierte. Es fühlte sich also wie ein geringfügiger Gewinn an.

Das war mit mehreren Mannjahren Arbeit in der Tasche, die die Assemblertechnologie, Bibliotheken und so weiter entwickelte. Zugegebenermaßen wurde viel davon für die Portierung aufgewendet. Wenn es nur eine Architektur zum Ziel gehabt hätte, wäre der alles singende, alles tanzende Assembler viel einfacher gewesen.

Fazit: Sie mögen C vielleicht nicht, aber es bedeutet nicht, dass der Aufwand für die Verwendung von C größer ist als der Aufwand, etwas Besseres zu finden.

6
Steve Jessop

Aus demselben Grund gehen wir nicht mehr auf die Toilette oder sprechen kein Latein oder Aramäisch.

Technologie kommt und macht Dinge einfacher und zugänglicher.

BEARBEITEN - um die Beleidigung von Menschen zu beenden, habe ich bestimmte Wörter entfernt.

5
Jack Marchetti

Die Baugruppe kann nicht zwischen verschiedenen Mikroprozessoren ausgetauscht werden.

5
semaj

Warum? Einfach.

Vergleichen Sie dies:

        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();
        }

mit

.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 

Sie sind in Bezug auf die Funktionen identisch. Der zweite ist nicht einmal Assembler, sondern .NET IL (Intermediary Language, ähnlich dem Bytecode von Java). Die zweite Kompilierung transformiert die IL in nativen Code (d. H. Fast Assembler), wodurch sie noch kryptischer wird.

4
Andrei Rînea

Ich denke, ASM auf sogar x86 (_64) ist in Fällen sinnvoll, in denen Sie viel gewinnen, indem Sie Anweisungen verwenden, für die ein Compiler nur schwer optimieren kann. x264 verwendet zum Beispiel viel asm für die Codierung und die Geschwindigkeitsgewinne sind enorm.

3
Maister

Das Gleiche gilt für das, was andere gesagt haben.

In der guten alten Zeit, bevor C erfunden wurde, als die einzigen Hochsprachen Dinge wie COBOL und FORTRAN waren, gab es viele Dinge, die einfach nicht möglich waren, ohne auf Assembler zurückzugreifen. Es war der einzige Weg, die volle Flexibilität zu erlangen, auf alle Geräte usw. zugreifen zu können. Aber dann wurde C erfunden und fast alles, was in der Montage möglich war, war in C möglich. Ich habe seitdem sehr wenig Assembly geschrieben dann.

Das heißt, ich denke, es ist eine sehr nützliche Übung für neue Programmierer, das Schreiben in Assembler zu lernen. Nicht weil sie es tatsächlich viel benutzen würden, sondern weil Sie dann verstehen, was wirklich im Computer passiert. Ich habe viele Programmierfehler und ineffizienten Code von Programmierern gesehen, die offensichtlich keine Ahnung haben, was wirklich mit den Bits und Bytes und Registern passiert.

2
Jay

Eine der frühen Entdeckungen (Sie werden es in Brooks 'Mythical Man-Month finden, das aus Erfahrung in den 1960er Jahren stammt) war, dass Menschen in einer Sprache mehr oder weniger produktiv waren als in einer anderen Fehlerbehebende Codezeilen pro Tag Dies ist offensichtlich nicht allgemeingültig und kann brechen, wenn es zu weit gedrängt wird, aber es traf im Allgemeinen auf die Hochsprachen der Brooks-Zeit zu.

Der schnellste Weg zur Produktivitätssteigerung wäre daher, Sprachen zu verwenden, bei denen eine einzelne Codezeile mehr bewirkt, und dies funktioniert tatsächlich, zumindest für Sprachen mit hoher Komplexität wie FORTRAN und COBOL, oder um ein moderneres Beispiel C zu nennen.

2
David Thornley

Portabilität ist immer ein Problem - wenn nicht jetzt, dann zumindest irgendwann. Die Programmindustrie gibt jedes Jahr Milliarden aus, um alte Software zu portieren, die zu der Zeit, als sie geschrieben wurde, "offensichtlich" überhaupt kein Portabilitätsproblem hatte.

2
Thomas Pornin

Es gab einen Teufelskreis, als Assembly immer seltener wurde: Mit zunehmender Sprachreife wurden Assembler-Befehlssätze weniger aus Gründen der Benutzerfreundlichkeit für Programmierer als vielmehr aus Gründen der Benutzerfreundlichkeit für Compiler erstellt.

Realistisch gesehen kann es daher sehr schwierig sein, die richtigen Entscheidungen zu treffen, z. B. welche Register Sie verwenden sollten oder welche Anweisungen etwas effizienter sind. Compiler können mithilfe von Heuristiken herausfinden, welche Kompromisse wahrscheinlich die beste Auszahlung haben. Wir können wahrscheinlich kleinere Probleme durchdenken und lokale Optimierungen finden, die unsere mittlerweile recht hoch entwickelten Compiler übertreffen könnten, aber es besteht die Wahrscheinlichkeit, dass ein guter Compiler im Durchschnitt beim ersten Versuch einen besseren Job macht als ein guter Programmierer. Irgendwann könnten wir wie John Henry die Maschine schlagen, aber wir könnten uns ernsthaft verbrennen, um dorthin zu gelangen.

Unsere Probleme sind jetzt auch ganz anders. 1986 versuchte ich herauszufinden, wie ich mit kleinen Programmen, bei denen ein paar hundert Pixel auf den Bildschirm gebracht wurden, ein bisschen schneller werden konnte. Ich wollte, dass die Animation weniger ruckelt. Ein fairer Fall für die Assemblersprache. Jetzt versuche ich herauszufinden, wie Abstraktionen in Bezug auf Vertragssprache und Servicer-Policy für Hypotheken dargestellt werden können, und ich möchte lieber etwas lesen, das der Sprache der Geschäftsleute ähnelt. Im Gegensatz zu LISP-Makros setzen Assembly-Makros die Regeln kaum durch. Obwohl Sie in einem guten Assembler möglicherweise etwas in der Nähe eines DSL finden, ist es anfällig für alle Arten von Macken, die gewonnen haben. ' Es bereitet mir keine Probleme, wenn ich denselben Code in Ruby, Boo, LISP, C # oder sogar F # geschrieben habe.

Wenn sich Ihre Probleme jedoch leicht in einer effizienten Assemblersprache ausdrücken lassen, erhalten Sie mehr Leistung.

2
JasonTrue

Ich programmiere jetzt seit ungefähr einem Monat in Assembly. Ich schreibe oft einen Teil des Codes in C und kompiliere ihn dann in Assembly, um mich zu unterstützen. Vielleicht nutze ich nicht die volle Optimierungsleistung des C-Compilers, aber es scheint, dass meine C-ASM-Quelle unnötige Operationen enthält. Ich beginne zu sehen, dass die Rede davon, dass ein guter C-Compiler einen guten Assembly-Codierer übertrifft, nicht immer wahr ist.

Wie auch immer, meine Montageprogramme sind so schnell. Und je mehr ich Assembly verwende, desto weniger Zeit brauche ich, um meinen Code zu schreiben, denn es ist wirklich nicht so schwer. Auch die Bemerkung über die schlechte Lesbarkeit der Versammlung trifft nicht zu. Wenn Sie Ihre Programme korrekt beschriften und Kommentare abgeben, wenn zusätzliche Ausarbeitungen erforderlich sind, sollten Sie bereit sein. Tatsächlich ist Assembly für den Programmierer klarer, weil er sieht, was auf der Ebene des Prozessors geschieht. Ich weiß nichts über andere Programmierer, aber ich mag es zu wissen, was passiert, anstatt Dinge in einer Art Black Box zu sehen.

Der eigentliche Vorteil von Compilern besteht darin, dass ein Compiler Muster und Beziehungen verstehen und diese dann automatisch an den entsprechenden Stellen in der Quelle codieren kann. Ein beliebtes Beispiel sind virtuelle Funktionen in C++, bei denen der Compiler Funktionszeiger optimal abbilden muss. Ein Compiler ist jedoch darauf beschränkt, das zu tun, was der Hersteller des Compilers dem Compiler erlaubt. Dies führt dazu, dass Programmierer manchmal auf bizarre Dinge mit ihrem Code zurückgreifen müssen, um die Codierungszeit zu erhöhen, wenn dies mit Assembly trivial möglich gewesen wäre.

Persönlich denke ich, dass der Marktplatz in hohem Maße Hochsprachen unterstützt. Wenn Assemblersprache die einzige Sprache wäre, die es heute gibt, dann würden etwa 70% weniger Menschen programmieren und wer weiß, wo sich unsere Welt wohl in den 90er Jahren befinden würde. Höhere Sprachniveaus sprechen einen breiteren Personenkreis an. Dies ermöglicht einer größeren Anzahl von Programmierern, die benötigte Infrastruktur unserer Welt aufzubauen. Entwicklungsländer wie China und Indien profitieren stark von Sprachen wie Java. Diese Länder werden ihre IT-Infrastruktur schnell entwickeln und die Vernetzung der Menschen verbessern. Mein Punkt ist also, dass Hochsprachen nicht deshalb beliebt sind, weil sie überlegenen Code produzieren, sondern weil sie dazu beitragen, die Nachfrage auf den Weltmärkten zu befriedigen.

2
user922475

Ich bin mir sicher, dass es viele Gründe gibt, aber ich kann mir zwei Gründe vorstellen

  1. Assembler-Code ist definitiv schwerer zu lesen (ich bin mir sicher, dass das Schreiben auch zeitaufwändiger ist)
  2. Wenn ein großes Entwicklerteam an einem Produkt arbeitet, ist es hilfreich, den Code in logische Blöcke zu unterteilen und durch Schnittstellen zu schützen.
2
Martin Konecny

Ich kann nur antworten, warum ich persönlich nicht öfter Programme in Assembly schreibe, und der Hauptgrund ist, dass es langwieriger ist, dies zu tun. Ich denke auch, dass es einfacher ist, Dinge subtil falsch zu machen , ohne es sofort zu bemerken. Sie können beispielsweise die Art und Weise ändern, in der Sie ein Register in einer Routine verwenden, vergessen jedoch, dies an einer Stelle zu ändern. Es wird gut zusammenbauen und Sie werden es vielleicht erst viel später bemerken.

Trotzdem denke ich, dass es immer noch gültige Verwendungen für die Versammlung gibt. Zum Beispiel habe ich eine Reihe von ziemlich optimierten Assembler-Routinen für die Verarbeitung großer Datenmengen mit SIMD und nach dem paranoiden Ansatz "Jedes Bit ist heilig" [Zitat V.Stob]. (Beachten Sie jedoch, dass naive Assembly-Implementierungen oft viel schlechter sind als das, was ein Compiler für Sie generieren würde.)

1
PhiS

Ich lerne gerade Assembly in der Comp-Organisation, und obwohl es interessant ist, ist es auch sehr ineffizient, darin zu schreiben. Sie müssen viel mehr Details im Kopf behalten, um die Dinge zum Laufen zu bringen, und es ist auch langsamer, die gleichen Dinge zu schreiben . Beispielsweise kann eine einfache 6-zeilige for-Schleife in C++ 18 Zeilen oder mehr Assembly entsprechen.

Persönlich macht es viel Spaß zu lernen, wie die Dinge auf Hardware-Ebene funktionieren, und es gibt mir eine größere Wertschätzung für die Funktionsweise von Computing.

1
Jason

Die Leute scheinen zu vergessen, dass es auch die andere Richtung gibt.

Warum schreibst du überhaupt in Assembler? Warum nicht das Programm in einer wirklich einfachen Sprache schreiben?

Anstatt von

mov eax, 0x123
add eax, 0x456
Push eax
call printInt

du könntest genauso gut schreiben

B823010000
0556040000
50 
FF15.....

Das hat also viele Vorteile, Sie kennen die genaue Größe Ihres Programms, Sie können den Wert von Anweisungen als Eingabe für andere Anweisungen wiederverwenden und Sie brauchen nicht einmal einen Assembler, um sie zu schreiben, Sie können eine beliebige verwenden Texteditor ...

Und der Grund, warum Sie Assembler immer noch bevorzugen, ist der Grund, warum andere Leute C bevorzugen ...

1
BeniBela

C ist ein Makro-Assembler! Und es ist das Beste!

Es kann fast alles, was Assembly kann, portabel sein und in den seltensten Fällen, in denen es etwas nicht kann, können Sie immer noch eingebetteten Assembly-Code verwenden. So bleibt nur ein kleiner Teil der Programme, die Sie unbedingt in Assembly schreiben müssen, und nichts als Assembly.

Und die höheren Abstraktionen und die Portabilität machen es für die meisten Menschen lohnender, Systemsoftware in C zu schreiben. Und obwohl Sie jetzt möglicherweise keine Portabilität benötigen, wenn Sie viel Zeit und Geld in das Schreiben eines Programms investieren, möchten Sie sich möglicherweise nicht einschränken in dem, wofür Sie es in Zukunft verwenden können.

1
ahe

Was C gegenüber einem guten Makro-Assembler hat, ist die Sprache C. Typprüfung. Schleifenkonstrukte. Automatische Stapelverwaltung. (Fast) automatische Variablenverwaltung. Dynamische Speichertechniken in Assembler sind ein großer Schmerz im Hintern. Eine verknüpfte Liste richtig zu machen, ist im Vergleich zu C oder besser, liste foo.insert () ziemlich beängstigend. Und das Debuggen - nun, es gibt keinen Wettbewerb darüber, was einfacher zu debuggen ist. HLLs gewinnen dort unten die Hände.

Ich habe fast die Hälfte meiner Karriere als Assembler geschrieben, was es mir sehr leicht macht, in Assembler zu denken. Es hilft mir zu sehen, was der C-Compiler macht, was mir wiederum hilft, Code zu schreiben, den der C-Compiler effizient handhaben kann. Eine gut durchdachte Routine, die in C geschrieben wurde, kann so geschrieben werden, dass mit ein wenig Arbeit genau das ausgegeben wird, was Sie in Assembler wollen - und es ist portabel! Ich musste bereits einige ältere ASM-Routinen aus plattformübergreifenden Gründen auf C zurückschreiben und es macht keinen Spaß.

Nein, ich bleibe bei C und werde mich mit der gelegentlichen leichten Abnahme der Leistung gegen die mit HLL gewonnene Produktivitätszeit auseinandersetzen.

1
Michael Dorgan

Weil es immer so ist: Zeit vergeht und auch gute Dinge vergehen :(

Aber wenn Sie asm-Code schreiben, ist das ein völlig anderes Gefühl als wenn Sie langs auf hoher Ebene codieren, obwohl Sie wissen, dass es viel weniger produktiv ist. Es ist, als ob Sie ein Maler wären: Sie können alles, was Sie möchten, ohne jegliche Einschränkungen nach Ihren Wünschen zeichnen (naja, nur nach CPU-Merkmalen) ... Deshalb finde ich es toll. Schade, dass diese Sprache weg ist. Aber während sich jemand noch daran erinnert und es codiert, wird es niemals sterben!

0
edk

$$$

Ein Unternehmen stellt einen Entwickler ein, der Code in $$$ umwandelt. Je schneller nützlich Code erstellt werden kann, desto schneller kann das Unternehmen diesen Code in $$$ umwandeln.

Höhere Programmiersprachen sind im Allgemeinen besser in der Lage, größere Mengen nützlichen Codes zu produzieren. Das soll nicht heißen, dass die Versammlung keinen Platz hat, denn es gibt Zeiten und Orte, an denen nichts anderes zu tun ist.

0
Sparky

Der Vorteil von HLLs ist noch größer, wenn Sie Assembly mit einer höheren Sprache als C vergleichen, z. Java oder Python oder Ruby. Diese Sprachen verfügen beispielsweise über eine Garbage Collection: Sie müssen sich keine Gedanken darüber machen, wann ein Teil des Speichers freigegeben werden soll, und es treten keine Speicherverluste auf oder Fehler aufgrund zu früher Freigabe.

0
user4660402

Wie bereits erwähnt, besteht der Grund für die Existenz eines Tools darin, wie effizient es arbeiten kann. Da HLLs die gleichen Aufgaben ausführen können wie viele Zeilen ASM-Code, ist es für Assembly eine Selbstverständlichkeit, von anderen Sprachen abgelöst zu werden. Und für das hardwarenahe Tüfteln gibt es Inline Assembly in C und andere Varianten je nach Sprache. Dr. Paul Carter in sagt in der PC-Assemblersprache

"... ein besseres Verständnis dafür, wie Computer auf einer niedrigeren Ebene als in Programmiersprachen wie Pascal funktionieren. Durch ein besseres Verständnis der Funktionsweise von Computern kann der Leser häufig viel produktiver Software in höheren Sprachen wie C entwickeln und C++. Das Programmieren in Assemblersprache ist ein ausgezeichneter Weg, um dieses Ziel zu erreichen. "

In meinen College-Kursen haben wir eine Einführung in Assembly. Es wird helfen, Konzepte zu klären. Ich bezweifle jedoch, dass einer von uns 90% des Codes in Assembly schreiben würde. Wie relevant sind heute vertiefte Kenntnisse in der Montage?

0
AruniRC