# Assembler schon ausgestorben oder noch wichtig?



## Knogle (22. Juni 2015)

Moin.

Beschaeftige mich schon seit einigen Jahren sehr mit x86-32 Assembler und bin sehr fasziniert davon.
Viele Anwendungen und andere Dinge lassen sich mit wenig Code und entsprechend kleinem Speicherbedarf realisieren und dabei wahrscheinlich ziemlich effizient. (In meinem Fall ein kleines Programm mit etwa 44KB)

Das ganze in Hochsprachen ausgedrueckt (In meinem Fall mit C++ versucht) ergibt eine Anwendung mit ueber 1MB Groesse (Tut jedoch letzendlich das gleiche)
(Werde ich nachher anhaengen)

Sowas duerfte ja auch besonders wichtig fuer z.B. wissenschaftliche Berechnungen sein, bei welchen man versucht moeglichst effizient Ergebnisse hervorzubringen.

Nun meine Frage:

Warum wird Assembler inzwischen so verteufelt? Es scheint ziemlich kompakt zu sein, und meiner Meinung nach eine sehr gute Moeglichkeit um hochoptimierten Code zu schreiben.
Eventuell ist Assembler komplex in der Wartung?

MS-DOS ist ja auch zu nem grossen Teil in Assembler geschrieben, und ist auch sehr kompakt mit ein paar MB Groesse fuer ein ganzes OS.

Hatte ebenfalls mal das BIOS meines P4 PCs aus 2001 untersucht, und dieses war nur 64kb Gross.
Zum Vergleich: Das BIOS meines 1366er Systems (kein UEFI) war schon 16MB Gross, obwohl die Funktion ja mehr oder weniger die selbe ist.


Waere es so nicht eigentlich moeglich massiv Ressourcen einzusparen, und so auch Programmie viel effizienter zu gestalten?

MfG


----------



## Incredible Alk (22. Juni 2015)

Knogle schrieb:


> Warum wird Assembler inzwischen so verteufelt?



Weil es ein sehr viel größeres Maß an Können voraussetzt als die meisten Hochsprachen und es bei sehr komplexen Aufgaben extrem schwierig wird das direkt in Assembler zu schreiben.




Knogle schrieb:


> Waere es so nicht eigentlich moeglich massiv Ressourcen einzusparen, und so auch Programmie viel effizienter zu gestalten?




Natürlich. Aber der Aufwand das zu tun ist sehr groß und rechnet sich nicht, da in 99,9% der Fälle auch das ineffizienteste Programm auf heutigen PCs mehr als schnell genug läuft. Die Hardware ausm Aldi ist heutzutage einfach so schnell dass man kaum mehr Mühe in Programmoptimierung stecken muss. Leider.


----------



## Imperat0r (22. Juni 2015)

Hochsprachen verkürzen gegenüber Assembler die Programmierzeit.Alles in Assembler zu schreiben ,braucht viel mehr Zeit.In einer Hochsprache sind die Programme also viel schneller fertig als in Assembler bzw. man braucht auch weniger Programmmierer.Der Fortschritt ist also eine Steigerung der Produktivität.


----------



## bingo88 (22. Juni 2015)

Assembler ist nicht ganz tot, aber aus der breiten Masse verschwunden. Assemblercode ist deutlich aufwendiger zu programmieren und zu pflegen. Zumal man ein sehr gutes Verständnis der Systemarchitektur haben muss, um effizienten Code zu schreiben. Außerdem ist Assembler nur eingeschränkt bis gar nicht portabel. Im Bereich der OS-Entwicklung müssen einige Dinge allerdings mit Assembler gelöst werden, auch bei Embedded-Anwendungen und der Codeoptimierung spielt Assembler zum Teil noch eine Rolle.

Die reine Dateigröße einer Anwendung sagt übrigens noch nichts über ihre Effizienz aus. Grundsätzlich gilt zwar weniger ist besser, das ist aber nicht das alleinige Kriterium. Zumal man auch ineffiziente Assemblerprogramme schreiben kann. Für Ungeübte ist das sogar die Regel als die Ausnahme, ein hochoptimierender Compiler erzeugt in der Regel besseren Code. Das Argument "Ressource sparen/Effizienz" gilt also nur, wenn das jemand macht, der sich damit wirklich gut auskennt - und diese Leute sind rar und teuer. Zumal das bei den meisten Anwendungen eh nicht erforderlich ist. Was interessiert mich bei 16 GB RAM, ob die Anwendung nun 1 MB oder 100 KB groß ist? In der Regel ist der Speicherverbrauch durch die Daten wesentlich höher, den bekommt man aber auch mit Assembler nicht kleiner (Byte bleibt Byte).

Ich würde da DOS jetzt auch nicht gerade als gutes Beispiel heranziehen, das ist zwar klein, kann aber auch fast nichts (Realmode, Single tasking, etc.). Auch das mit dem BIOS kannst du pauschal so nicht sagen, gerade bei Serversystemen ist da viel zusätzlicher Kram drinnen.

BTW Wie hast du deine Programme verglichen? OS, Compilerflags, etc.?


----------



## Knogle (22. Juni 2015)

Beim BIOS bin ich jetz von nem Desktop Board ausgegangen, weshalb mich das so verwundert hat


----------



## bingo88 (22. Juni 2015)

Bei Onboard-LAN mit PXE-Support brauchst du ja beispielsweise auch den PXE-Code im BIOS. Das beschränkt sich also nicht nur auf die reine Hardwareinitialisierung. Bei modernen OS spielt das BIOS nach dem Boot eh keine Rolle mehr, insofern wäre da auch nicht viel zu optimieren. Das klassische BIOS war eigentlich sowieso Assembler, ob UEFI mittlerweile auch Hochsprachen kann, weiß ich nicht. Jedenfalls gibt es nur eine handvoll Leute, die das Programmieren können.

Was sollte dein Testprogramm denn machen, dass dein C++ Compiler da eine 1 MB Binary ausspuckt (OS, Compilerflags, etc.)?


----------



## JimSim3 (22. Juni 2015)

Assembler ist aufwendig und zeitraubend. Es ist oftmals wesentlich günstiger einfach nen fetteren Rechner hinzustellen, anstatt nen Programmierer zu beschäftigen um das ganze in Assembler zu programmieren. Zum einen weil es länger dauert, zum anderen weil sich keine Sau das antun will. Die wenigen Programmierer die sich dennoch gegen Geld mit Assembler rumschlagen kosten richtig viel Geld... Für das Geld das die kosten stell ich dir ne Serverfarm hin.


----------



## Olstyle (22. Juni 2015)

Die Firma in der ich arbeite verkauft noch ein paar Produkte die zur großen Teilen in Assembler programmiert sind (Schlüssel der aktuellen BMWs z.B.). Aufgrund der Wartbarkeit und Portierbarkeit wird das aber selbst bei den ganz kleinen Systemen mittlerweile nicht mehr gemacht.
Grundsätzlich Assembler zu verstehen ist aber trotzdem weiterhin sehr hilfreich wenn es ans Debuggen geht.


----------



## XPrototypeX (23. Juni 2015)

Ich denke es ist nicht so ohne weiteres möglich schnelleren Assembler Code zu schreiben, als der Compiler nicht eh schon kompilieren würde. Gerade bei Assembler versucht man einen sauberen, lesbaren Code zu schreiben, damit auch andere Entwickler nicht Tage brauchen um den Sinn zu verstehen. In keiner weiße zu vergleichen mit hoch optimiertem Assembler Code (in der Regel kennt der Compiler die verwendete Architektur besser und kann ggfs. noch auf spezielle Cpus optimieren) . 

Generell wird Assembler noch in den meisten Os verwendet um sehr Hardwarespezifische Sachen abzubilden. Auch im Security Bereich findet man großen Einsatz von Shellcode / Opcode bzw. komplette Assembler Sections.


----------



## Ap0ll0XT (23. Juni 2015)

Ich denke man kann ganz einfach sagen, das Assembler nie aussterben kann. Denn Assembler ist auch heute noch DER Kompromiss zwischen echten Maschinencode und Hochsprache. Mit Assembler kann man im Grunde fast alles machen und bildet die Grundlage für besonders zeitkritische Algorithmen. Die meisten Hochsprachen (da ich nicht alle kenne, kann ich nicht von allen sprechen) haben grundsätzlich auch einen Inline-Assembler, mit dem man eine Hochsprache mit Assembler mischen kann. Alles, was noch keinen Hochsprachencompiler hat, wird noch mit Assembler programmiert. ARM zum Beispiel hatte zu Anfang auch keine Compiler für C/C++. Es gibt noch viele Bereiche, wo es genutzt werden muss. Aber die meisten Bereiche bekommen wir eh nicht mit. Ob man Assembler nun lernen möchte hängt vom Einsatzgebiet ab. Aber wenn man größere Projekte oder Anwendungen schreiben will, dann ist es weder produktiv, noch ist es wirklich sicherer. Es sei denn man beherrscht es durchweg. Doch selbst dann ist es nicht wirklich produktiv.


----------



## Crysis nerd (23. Juni 2015)

Wie XPrototypeX sagt: 
Assembler ist keineswegs automatisch schneller als eine Hochsprache. Es wird sogar immer schwieriger, von Hand schnellen Assembler-Code zu schreiben (+ hoch optimierter Assemblercode ist noch schlimmer zu lesen und zu warten, als normaler Assembler Code). CPUs sind immens komplex geworden und nur jemand, der sich Jahre mit einer bestimmten CPU Architektur beschäftigt, weiß genau, welche Tricks ein Programm beschleunigen. Und wo arbeiten solche Leute größtenteils? Richtig: Im Compilerbau. Es gibt halt nur wenig Leute, die viel Ahnung über eine Architektur haben und die arbeiten oft an dem Optimierer eines Compilers. Es ist immer möglich, dass der Compiler für eine Stelle Code generiert, der nicht optimal ist. Für die beste Performanz sind dort dann Anpassungen von Hand nötig. 
Aber: 98% aller Programme müssen nicht wirklich auf Performanz achten. Von den restlichen 2% der Programmen ist 98% vom Code "cold", wird also nur selten ausgeführt und hat daher nicht wirklich große Auswirkungen auf die Performance. Und die restlichen 2% des Codes werden zu 98% vom Compiler schon perfekt effizient generiert. Man kann also verstehen, warum Assembler nur noch selten benutzt wird (und benutzt werden muss!).
Moderne Optimizer in Compilern sind wirklich unglaublich mächtig. Die allermeisten Leute unterschätzen Compiler. Es ist Wahnsinn, was für High-Level Ausdrücke in höchst effizienten Code verwandelt werden. Und vielen Leuten, die immer meinen, Assembler von Hand ist besser, würde ich nahelegen mal etwas in C++ o.ä. zu schreiben und den generierten Code anzugucken. Die Meisten sind dann sehr überrascht.



Knogle schrieb:


> Waere es so nicht eigentlich moeglich massiv Ressourcen einzusparen, und so auch Programmie viel effizienter zu gestalten?


Programmierer(-Stunden) sind auch eine Ressource. Und zwar eine viel kostbarere als Hardware.


----------



## Olstyle (23. Juni 2015)

Wobei es anders herum auch wirklich dumme Compiler gibt. Hatte ein Kollege erst heute wieder.
A=A>>2 :
Lade A aus dem Speicher, Kopieren A in ein Register, Shifte um 2, Kopiere A aus Ergebnisregister in Speicher.
A>>=2:
Nutze Barrel-Shifter auf Speicheradresse.

Im Allgemeinen kann ich dem oben geschriebenen aber nur zustimmen.


----------

