ASM vs C
Sowohl Assembler, C als auch Sprachen, die noch weiter abstrahieren, wie C++, Java, haben ihre Existenzerechtigung. Allerdings macht einem eine Optimierung von Programmen und gfs Anpassung an neue Prozessorenderivate mit steigendem Umfang und Komplexität der Programme immer mehr zu schaffen. Bei zeit- und prozessoroptimierten Assemblerprogrammen sind viel mehr Adaptionen zu leisten, als bei den Hochsprachen.
Bei typischen Applikationen für AVR, 8051 oder PIC ist dies meist noch relativ problemlos mögich, da die Codegröße und Strukturvielfalt begrenzt sind. Bei diesen Prozessoren kann man die Abarbeitung der Maschinenbefehle praktisch zu 100% voraussehen, ohne viel "um die Ecke" denken zu müssen.
Bei einem ARM7, mit seiner 3-stufigen Pipeline, wird dies schon schwieriger und bei einem P4 gar, mit seiner über 20-stufigen Pipeline, out of order execution und anderen Optimierungen ist das nur sehr schwer zu durchschauen, insbesondere für Entwickler geschwindigkeitskritischer Software. Der Konstrukteur des Compilers, der die Hochsprache in machinen- und z.T. sogar anwendungsoptmiertes ASM übersetzt, kann dies besser, da er erstens die Architektur sehr gut kennt und sich zweitens mit nichts anderem als Codegeneration beschäftigt. Hier lohnt eine intensive Einarbeitung in die von den Prozessorenherstellern vorgeschlagenen Optmierungsstrategien im Bezug auf einzelnen Anwendungsfälle (Stackbehandlung, Funktionsaufrufe, Akkumulator- und pipeline-handling).
Die Nutzung der Hochsprache garantiert auch ein automatisches Mitwachsen der Anwendung, wenn neue Prozessoren herauskommen, defekte Teilfunktionen von Prozessoren übergangsweise mit workarounds belegt werden müssen, oder mit neuen Generationen von Derivaten neue Möglichkeiten der Optimierung gegeben sind. Von solchen Optimierungen, die in neuere Compilerversionen einfliessen, kann man auf diese Weise quasi kostenlos profitieren. Ein Beispiel dafür:
POVRay (mehrere Megabyte C++ Sourcecode) compiliert für P4 mit GCC 3.4.0 bringt gegenüber GCC 3.3.1 eine Leistungssteigerung von knapp 7%. Um diese 7% per Assembler-Optimierung zu erreichen würden wohl einige Tage Arbeitsaufwand nötig, sofern es überhaupt gelingt.
Nur, wenn es wirklich auf das letzte bisschen Leistung ankommt, z. B. im Bereich von Treibern und der Ansteuerung von Hardware, kann der Einsatz von Assembler an entscheidenden Stellen durchaus Sinn machen. Dies gilt insbesondere für Massenanwendungen kleiner Controller, bei der eine Verbilligung viel Geld einspart, bzw. die Optimierung von Code zusätzlichen Platz für neue, dringend benötigte Funktionenen schafft, die sonst einen größeren Controller erfordert hätten. Für einen neue Produktzykus ist aber oftmals billiger, für die kommende Generation einfach schnellere Hardware einzusetzen, als tagelang über Assembler-Code zu brüten und teure Entwicklerstunden zu investieren.
In der Industrie beobachtet man daher auch eine immer stärkere Abkehr von ASM hin zu zumindest der Hochsprache C, teilweise jedoch auch bereits JAVA. ASM wird nur noch dort intensiv eingesetzt, wo eine lange Projekt- und Gerätehistorie anzutreffen ist, die ausschließlich auf ASM basiert und nicht kostenoptimiert umgestellt werden kann.