Warum es immer noch Sinn macht, Assembler zu lernen.

Anmerkung:
Der nachfolgende Artikel wurde ursprünglich geschrieben mit Intel-Type Prozessoren im Hinterkopf und meint eigentlich deren Assembler. Da die vom Autor präsentierten Argumente auch auf den Mainframe zutreffen, dachten wir, dass es hilfreich ist, diesen Artikel auch auf hlasm.com zu veröffentlichen.

Disclaimer: (left on purpose in english):
Bixoft converted "Why Learning Assembly Language Is Still a Good Idea" into a web-document with permission of the original author for re-publication. We also applied several minor changes. Nevertheless, the copyrights of Mr. Hyde still apply to the document below.

Disclaimer:
Pi-Sysprog hat diesen Text aufgrund des von Bixoft als web-document präsentierten Artikels übersetzt. Kleinere Übersetzungsfreiheiten sind möglich. Nichtsdestotrotz: Das Copyright des Originals verbleibt bei Herrn Hyde. Das Copyright der deutschen Übersetzung liegt gemeinsam bei Herrn Hyde und Herrn Trü bner

Contact:
Mr. Hyde nimmt Ihre Kommentare, Anmerkungen etc. unter dieser E-Mail an: e-mail Randall hyde.

Dieser Artikel enthält folgende Abschnitte:

Großartiger Code geht weiter
Effizienz ist der Schlüssel
Bleiben Sie fit
Lerne Sie Assembler
Assembler ist nicht tot
Basis-Instruktionen verstehen
Zusammenfassung

Großartiger Code geht weiter

Die Welt ist voll von Fallstudien über Software-Entwicklungs-Desaster. Fast jeder Programmierer hat schon in Projekten gearbeitet, in denen er an "nicht optimalem" Quell-Code arbeiten musste. In seltenen Fällen bekommen Programmierer die Gelegenheit, an gutem, ordentlich entworfenem und implementiertem Code zu arbeiten. Code, der nach allen Regeln der Kunst geschrieben ist und zu Ausrufen wie "Das ist wirklich großartiger Code" Anlass gibt.

Natürlich sollte jeder professionelle Softwareentwickler diese Qualitätsstufe in jedem Code anstreben. Aber die grundlegende Frage ist: "Was macht Code großartig?". Einfach nur "trifft die Spezifikationen" ist es wahrscheinlich nicht. Sicher, in den heutigen Software-Entwicklungs-Umgebungen mag manch einer glauben, dass ein einfaches Erfüllen der Spezifikationen eine Anwendung hervorhebt, da viele Projekte bereits an dieser Basisforderung scheitern.

Jedenfalls wird in anderen Bereichen "großartig" selten durch das erwartete Handeln definiert: "Großartigkeit" ist definiert durch: über das Übliche und Erwartete hinausgehen. Softwareentwickler sollten nicht weniger von "großartiger" Software erwarten - sie sollte über die Standardkonventionen hinausgehen.

Effizienz ist der Schlüssel

Die "Großartigkeit" hat viele Seiten, daher kann ein kurzer Artikel wie dieser nicht alle Komponenten von "großartiger" Software beschreiben. Stattdessen wird dieser Artikel eine Komponente dieser "Großartigkeit" beschreiben, die in den letzten Jahren vernachlässigt wurde. Dies insbesondere, weil Computersysteme in ihrer Kapazität und Mächtigkeit enorm erweitert wurden: Effizienz

Jeder, der in der Computerbranche seit einer Dekade oder mehr aktiv ist, kennt das Phänomen: Maschinen werden exponentiell zu ihren Kosten mächtiger, aber Endanwender sehen diese Verbesserungen in den Anwendungen, die sie nutzen, nicht. Zum Beispiel ist Textverarbeitung heute schneller als vor 21 Jahren, aber bei weitem nicht 16,384-mal so schnell wie Moore's Gesetz [1] erwarten lässt. Teil des Problems ist natürlich, dass etwas von der zusätzlichen Verabeitungsgeschwindigkeit für neue Eigenschaften (z.B. bitorientierte Anzeige) genutzt wird, aber ein Großteil der Gründe, warum Softwarebenutzer keinen Geschwindigkeitszuwachs sehen, liegt daran, dass viele der heutigen Programmierer sich nicht die Zeit nehmen, effiziente Software zu schreiben, oder sie wissen einfach nicht, wie schnelle Software erstellt wird.

Kurze Softwareentwicklungenszeiträume geben den Programmierern nicht genug Zeit, um effizienten Code zu entwickeln. Dies ist sicher ein Problem, aber viele der heutigen Programmierer sind aufgewachsen mit schnellen CPUs, deren Geschwindigkeit schlechte Kodiergewohnheiten ausbügelt. Daher haben viele dieser Programmierer niemals lernen müssen, wie man schnellen Code schreibt.

Wenn die Softwareperformance suboptimal ist, wissen diese Programmierer unglücklicherweise im Allgemeinen nicht, wie sie das Problem mit ihrer Software beheben. Aussagen wie "Die 90-10 Regel" oder "Ich werde einen Profiler einsetzen, um das Performanceproblem zu beheben" kann man hören- Aber die Wahrheit ist: Sie wissen nicht, wie sie die Performance ihrer Anwendung verbessern. Es ist leicht zu sagen "Ich werde einen besseren Algorithmus einsetzen!". Schwierig wird es, ihn zu finden (wenn es denn einen gibt) und gar umzusetzen. .........korrekter

Meistens kann man sehr gute Performanceverbesserungen erzielen indem man die Umsetzung eines existierenden Algorithmus verbessert. Wissenschaftlich betrachtet mag man argumentieren, dass eine konstante Performanceverbesserung nicht so gut ist wie das Wechseln des Algorithmus A (z.B. von n hoch 2 Durchläufen zu n lg n Durchläufen), aber in Wahrheit kann eine konstante Verbesserung in einer gegebenen Software den Unterschied zwischen einer praktischen Anwendung und einer, die einfach zu langsam ist, um benutzt zu werden. Und es ist exakt diese Art der Optimierung mit der viele der heutigen Programmierer wenig Erfahrung haben.

Unglücklicherweise ist das Schreiben effizienter Software eine Fertigkeit, die man durch Übung erwerben kann. Diese Fertigkeit muss man aber auch üben, um sie zu erhalten. Programmierer die diese Fertigkeit nie geübt haben, werden niemals in der Lage sein, sie an dem Tag, an dem entdeckt wird, dass ihre Software zu langsam läuft, einzusetzen. Sogar ein Programmierer der diese Fähigkeit beherrscht, muss diese regelmäßig anwenden. Es gibt also zwei Gründe warum manche Programmierer keinen effizienten (und damit großartigen) Code schreiben: Sie haben es nie gelernt oder ihre Kenntnisse sind verkümmert.

Bleiben Sie fit

Für Programmierer die einfach nur versäumt haben, ihre Fähigkeit zu trainieren ist die Lösung einfach: "Übe regelmäßig effizienten Code schreiben, auch wenn das Projekt nicht absolut erfordert". Dies heißt natürlich nicht dass für Übungen Projektpläne, les- und pflegbarer Code oder andere wichtige Softwareattribute geopfert werden sollen.

Es heißt dass der Entwickler beim Entwurf und bei der Umsetzung Effizienz im Hinterkopf behalten sollte. Der Entwickler sollte eine bewusste Entscheidung zwischen einer weniger effizienten Umsetzung und einer besseren Umsetzung basierend auf ökonomischen und technischen Gründen treffen, statt die erste Implementation die zufällig eingefallen ist zu nutzen. Genauso oft wie nicht ist diese einfache Entscheidung zwischen unterschiedlichen (und möglicherweise effizienteren) Umsetzungen die Grundlage für großartigen Code. Schließlich ist oft die effizientere Umsetzung genauso leicht zu erstellen wie die uneffektive. Alles was ein erfahrener Entwickler manchmal benötigt sind Alternativen.

Unglücklicherweise haben unrealistische Zeitpläne viele Entwickler verführt, die gründliche Entwicklung und Umsetzung zu verkürzen. Das Ergebnis ist das viele Entwickler nicht mehr gewöhnt sind großartigen Code zu schreiben. Zum Glück kann dieser Vorgang leicht rückgängig gemacht werden, indem man gute Softwareentwicklungsmethoden so oft als möglich übt, wie zum Beispiel das Berücksichtigen mehrerer Algorithmen.

Lernen Sie Assembler

Und was ist nun mit dem Entwickler der nie gelernt hat effizienten Code zu schreiben? Wie lernt man effiziente Umsetzung einer Anwendung? Universitäten und Hochschulen haben den Standpunkt, dass wenn ein guter Algorithmus gewählt wird, man sich nicht mehr über dessen Umsetzung den Kopf zerbrechen muss. Viel zu viele Studenten kommen aus ihren Datenstruktur- und Algorithmen-Kursen mit der Vorstellung, das wenn man nur eine konstante (das ist, O(1)) Verbesserung erzielen kann, hat man nichts erreicht und jeder Versuch einer Verbesserung ist eine Zeitverschwendung.

Fortschritte in der Computer-Architektur haben diese Problem noch verstärkt - zum Beispiel mag man einen Programmierer hören, "Wenn dieses Programm ein bisschen schneller sein soll, warte ein Jahr oder so und CPUs werden doppelt so schnell sein; es gibt keinen Grund sich Gedanken zu machen." Und diese Einstellung, mehr als jede andere, ist der Grund das Software-Performance nicht Schritt gehalten hat mit CPU-Performance.

Mit jeder neuen Anwendung schreibt der Programmierer die Software langsamer als sie sein sollte. Im festen Glauben das zukünftige CPU-Performance-Schübe das Problem lösen werden. Natürlich ist die Software, wenn die CPU dann schnell genug ist, "erweitert" und braucht eine weitere Version von Hardware. Der Zyklus wiederholt sich fast endlos, mit einer CPU-Performance die niemals wirklich aufholt zum Bedarf der Software, bis schließlich die Software zu Ihrem Nutzungsende kommt und der Entwickler den Zyklus mit einer neuen Anwendung wiederholt.

Die Wahrheit ist, es ist möglich Software zu schreiben die effizient auf gebräuchlichen Prozessoren läuft. Programmierer haben großartige Dinge getan mit Software in den Tagen in denen ihre Anwendungen auf acht-bit 5MHz 8088 PCs (oder noch früher auf 0.01 Mips Mainframes); die gleiche Technik die damals genutzt wurde um auch das letzte Bisschen aus diesen CPUs zu quetschen enthält die Lösung für exzellente Performance von heutigen Anwendungen. Wie also wurde befriedigende Performance aus diesen langsamen Prozessoren herausgeholt? Die Antwort ist kein Geheimnis - Man verstand wie die darunterliegende Hardware funktionierte und man schrieb den Code entsprechend. Diese Kenntnis der unterstützenden Hardware ist auch heute der Schlüssel zum Schreiben effizienten Codes.

Oft hört man old-time Programmierer sagen das effiziente Software in Assembler geschrieben ist. Aber der Grund das solche Software effizient ist liegt nicht in irgendeiner magischen Effizienz die durch die Sprache der Umsetzung in die Software eingepflanzt wird - es ist sehr gut möglich ineffiziente Software in Assembler zu schreiben. Nein der wahre Grund das Assembler-Programme tendenziell effektiver sind als Programme in anderen Sprachen ist weil Assembler den Programmiere zwingt mit jeder Anweisung, die er schreibt, zu berücksichtigen wie die darunterliegende Hardware funktioniert. Und das ist der Schlüssel zum lernen wie effizienter Code geschrieben wird - Im Auge behalten wo die Möglichkeiten der Maschine liegen.

Die gleichen Old-timer, die behaupten das wirklich effiziente Software in Assembler geschrieben ist, haben einen weiteren Hinweis - Wenn man lernen möchte großartigen Hochsprachen-Code zu schreiben, soll man programmieren in Assembler lernen.

Sehr guter Ratschlag. Schließlich übersetzen Hochsprachen-Compiler die Hochsprachenanweisungen in Maschinen-Code. Wenn man also Assembler für spezielle Maschine kennt, kann man sich die Maschinensprache, die aus den Hochsprachenkonstrukten generiert wird, vorstellen. Mit dieser Vorstellung, kann man bessere Hochsprachenkonstrukte schreiben.

Viel zu oft wählen Hochsprachenentwickler eine spezielle Instruktionsfolge ohne jedes Wissen der Ausführungskosten dieser Instruktionen. Das Lernen von Assembler zwingt die Programmierer die Kosten, verbunden mit den verschiedenen Hochsprachekonstrukten, zu erkennen. Selbst wenn ein Entwickler niemals in Assembler programmieren wird, macht das Wissen bewusst welche Probleme mit bestimmten uneffektiven Instruktionsfolgen verbunden sind, und können somit vermieden werden in ihrem Hochsprachen-Code.

Das lernen von Assembler, wie jede neue Programmiersprache, erfordert erhebliche Anstrengungen. Das Problem ist das Assembler trügerisch einfach erscheint. Man kann die 20 oder 30 Maschineninstruktionen, die in den meisten Assembler-Anwendungen genutzt werden, in ein paar Tagen lernen. In ein paar Wochen kann man sogar lernen diese Maschineninstruktionen so zu kombinieren, dass man die gleichen Probleme, die man in Hochsprachen gelöst hat, löst.

Unglücklicherweise ist dies nicht die Art von Kenntnis, die ein Hochsprachenentwickler nützlich finden wird, um effizienten Hochsprachen-Code zu schreiben.
Um den Vorteil der Assemblerkenntnis zu nutzen, muss ein Entwickler lernen in Assembler zu denken. Dann kann ein solcher Programmierer sehr effizienten Hochsprachen-Code schreiben.

Obwohl so geschriebener Code wirklich großartig ist, gibt es ein kleines Problem mit dieser Vorgehensweise - Es braucht gehörige Anstrengungen um diesen Zustand zu ereichen. Dies ist einer der Gründe warum solcher Code großartig ist - weil es so wenig Praktiker gibt die fähig sind ihn zu produzieren.

Assembler ist nicht tot

Assembler entwickelte einen sehr schlechten Ruf in den neunziger Jahren. Fortschritte im Compilerbau, schnellere CPUs und die "Softwarekrise" haben alle mitgewirkt an der Vorstellung das Assembler eine "tote" Sprache ist und man sie nicht länger braucht. Weil Assembler ein bisschen schwerer zu lernen ist als normale Hochsprachen, Stundenten (und Lehrer) haben sich der schönen neuen Hochsprachenwelt hingegeben und aufgegeben diesen schwer zu lernenden Assembler zu vermitteln.

Das zentrale Problem mit dem Verschwinden von Assembler ist das immer weniger Programmierer die Folgen ihres Codes auf Maschinenlevel verstehen.
Die Programmierer die das Ende von Assembler verkündeten, dachten in Assembler und konnten dieses Denken beim Schreiben von Hochsprachen-Code nutzen. Aber mit der Ankunft neuer Programmierer, die nicht mehrere Anwendungen in Assembler geschrieben haben, begann sich die Effizienz der Software zu verringern.

Obwohl es dumm wäre zu fordern das Programmierer kommerzielle Software in Assembler zu schreiben, ist es heute klar das die Verringerung der Kenntnis in Assembler umfangreiche Folgen hat für die Effizienz moderner Software. Um diesen Trend umzukehren muss eine von zwei Dingen passieren: Programmierer müssen wieder Assembler studieren, oder sie müssen diese low-level Programmierkenntnisse auf andere Art erwerben.

Das Lernen von Assembler bleibt die beste Methode die Struktur der darunterliegenden Maschine kennen zu lernen. Die Programmier die diese Anstrengung auf sich nehmen, werden die besten Hochsprachen Programmierer werden. Ihre Fähigkeit die entsprechenden Hochsprachenkonstrukte auszuwählen um effizienten Code zu produzieren, ihre Fähigkeit disassemblierten Hochsprachen-Code zu lesen um den absonderlichste Fehler in einem System zu entdecken und ihr Verständnis des gesamten Systems erhebt sie zu annähernd legendärem Status unter ihren Kollegen. Das sind die Programmierer die man aufsucht wenn Fragen auftreten wie etwas umzusetzen ist. Das sind die Ingenieure die den Respekt aller ernten. Das sind die Vorbilder von Entwicklern. Das sind die Programmierer die großartigen Code schreiben.

Wenn die Kenntnis von Assembler hilft einen Programmier großartig zu machen, ist eine offensichtliche Frage "Warum lernen dann nicht mehr Programmierer Assembler?" Ein Teil des Problems ist Voreingenommenheit: Viele Hochschul- und Universitätstrainer beginnen einen Assemblerkurs mit Sprüchen wie diesen: "Niemand braucht dieses Zeugs eigentlich, und Sie werden es niemals benutzen, aber es ist Bestandteil dieses Programms. Also werden wir uns durch die nächsten Wochen abmühen dieses Material zu studieren." Nach vier Jahren mit dieser Attitute vom Trainer ist es nicht verwunderlich wenn Studenten nichts mit zu tun haben wollen mit Assemblerprogrammierung.

Wenn es einmal für den Codierer offensichtlich geworden ist, dass wirklich großartige Programmierer die sind, die Assembler beherrschen, warum versuchen dann nicht mehr Programmierer diese wertvolle Fähigkeit zu erwerben. Das Problem ist das es viele Programmierer als schwer empfinden Assembler zu meistern. Assembler ist grundsätzlich unterschiedlich zu den meisten Hochsprachen. Das Lernen von Assembler ist daher fast wie das neue Lernen von Programmieren.

Für jemanden der versucht Assembler zu lernen ist es oft so dass ihre bisherige Programmiererfahrung scheinbar nichts nutzt. Zu oft wird ein Lernender frustriert durch die Tatsache das man sehr wohl weiß wie das Ziel in einer Hochsprache zu erreichen ist, aber das selbe Ziel in Assembler erscheint unerreichbar. Für viele Programmierer ist das umschalten vom Denken in Hochsprache zum Denken in Assembler ein unüberwindliches Hindernis.

Als Instruktor für Assembler für mehr als 10 Jahre an der University of California, bin ich mir bewusst über die Probleme der Studenten beim Umschalten von Hochsprachenprogrammierungs-paradigma zum Low-Level-Programmierungs-paradigma.

In den frühen 90er Jahren hat Microsoft mit der Einführung des Microsoft Macro Assembler (MASM) v6.0 eine Lösung geboten - Die Einschließung von Hochsprachen-Kontrol-Strukturen in eine Assembler-Übersetzer. Wiewohl diese neuen Instruktionen definitiv keine Assembler-Sprache sind, boten sie doch einen schönen Übergang von traditionellen befehlsorientierten Hochsprachen zu Assembler. Ein Programmierer kann weiterhin seine Instruktionen wie IF, WHILE und FOR während er andere Aspekte von Assemblerprogrammen lernt. Dies erlaubt einen schrittweise Übergang statt einem großen einmaligen Schritt.

Ebenso existieren seit vielen Jahren für IBM's High-Level Assembler (HLASM) verschiedene Bibliotheken, die die gleichen Funktionen zur Verfügung stellen.

Basis-Instruktionen verstehen

Natürlich kann sich ein Programmierer nicht Assembler Programmierer nennen bis er es geschafft hat die Basisinstruktionen zu verstehen. Nichtsdestotrotz bieten diese Kontroll-Strukturen einen exzellenten Übergang zwischen Hochsprachen und Assembler. Weiterhin gibt es verschiedene Bücher die Assembler Programmierung mit dieser top-down Methode lehren.

Ein weiteres Problem mit dem top-down Übergang ist das viele Hochsprachen eine große Bibliothek mit Routinen besitzen, welche so Allerweltsaufgaben wie Ein/Ausgabe, numerische Konvertierung, und Kettenoperationen erledigen. Ein großes Problem für Assembleranfänger ist das sie typischerweise Ein/Ausgabeoperationen, numerische Konvertierung und Kettenoperationen benötigen um einfache Programme zu schreiben und zu testen. Unglücklicherweise überlassen es viele Assembler Entwicklungssysteme dem Programmierer diese Funktionen für ihre Anwendungen selbst bereitzustellen. Hier beißt die Katze sich in den Schwanz: Es ist schwer Assembler ohne diese Funktionen zu lernen, aber man kann solche Funktionen nicht schreiben, wenn man nicht Assembler kann.

Anmerkung:
HLASM bietet eine große Anzahl Standardmacros für Ein/Ausgabeoperationen. Für numerische Konvertierungen gibt es diverse Instruktionen in Assembler. Dies ergibt einen Vorteil für HLASM-Studenten gegenüber MASM-Studenten.

Diese Blockaden halten alle (bis auf die wirklich hartnäckigen) ab Assembler zu beherrschen. Daher nimmt die Benutzung von Assembler seit 1990 konstant ab. Im Angesicht der abnehmenden Software-Effizienz und -qualität, die parallel zur Abnahme der Benutzung von Assembler läuft, habe ich mich Mitte der 90er Jahre zu einem Kreuzzug, zur Ermunterung von Programmierern die Assemblersprache zu lernen, entschlossen.

Der erste von mir erreichte Meilenstein war die Freigabe der elektronischen Version von "The Art of Assembly Language". Dieses Buch, mit der begleitenden "UCR Standard Library for 80x86 Language Programmers", vermindert den Aufwand Assembler zu lernen. Zehntausende von Programmierern haben Assembler programmieren gelernt mit diesem Textbuch und den ergänzenden Bibliotheksroutinen.

Das einzige Problem mit der elektronischen Version von "The Art of Assembly Language" und der "UCR Standard Library for 80x86 Assembly Language Programmers" ist das sie fast überflüssig wurden in dem Moment in dem sie veröffentlicht wurden, weil sie dem Leser beibrachten wie man 16-Bit DOS Anwendungen programmiert (Ihre Veröffentlichung ist fast zeitgleich mit der Freigabe von Windows 95, welches einer der letzten Sargnägel für 16-bit Programme war).

Im noch auf dem Kreuzzug, habe ich angefangen an dem brandneuen, high-level assembler (HLA, the High-Level Assembler), einer neuen Version von "The Art of Assembly Language" und einem neuen HLA-basierenden Satz von Bibliotheksroutinen zu arbeiten. Die Anstrengung gipfelte in der Veröffentlichung der "published edition of The Art of Assembly (AoA)" in 2003. Bis heute haben tausende und abertausende von Programmierern enthusiastisch diese neue Methode Assembler zu lernen benutzt.

Obwohl "The Art of Assembly Language" und "HLA" die Qualifizierung der Assemblerprogrammierer jeden Tag steigern, ist dies eine Lösung für die nächste Generation von Programmierern.

Was ist mit den jetzigen Programmierern die es versäumt haben in der Schule Assembler zu lernen und die Konzepte von Maschinen zu bernerschen, bevor das Leben in Form von knappen Zeitplänen sie einholt. Einholt bevor sie die nötige Erfahrung gesammelt haben um großartigen Code zu schreiben. Die Frage ist, "Können Maschinenorganisation effektiv an professionelle Programmierer vermittelt werden ohne gleichzeitig Assembler zu lehren?"

Es ist klar, das der beste Rat den ich geben kann "lerne Assembler" ist, dennoch bin ich überzeugt dass man Maschinenorganisation ohne Assembler studieren kann und dadurch lernt besseren Code zu schreiben. Dieser Code mag vielleicht nicht so gut werden wie der von Programmierern die Assembler beherrschen, aber er wird besser als der Code der vorher ohne das neue Wissen produziert wurde.
Und am Wichtigsten, obwohl es schwer ist die Idee Assembler zu lernen an die derzeitige Generation von Programmierern zu verkaufen (zwei Jahrzehnte Anti Assembler Propaganda haben das sicher gemacht), erkennen viele Programmierer, wenn sie nur ein bisschen mehr lernen würden über die darunterliegenden Hardware könnten sie besseren Code schreiben. Ergo ist alles was nötig ist ein Satz Material welcher Datenrepresentation Speicherorganisation, Elemente einer Rechnerarchitektur, wie Ein/Ausgabe funktioniert und die Relation zwischen Hochspracheninstruktionen.

Das heißt, lehrt ihnen alles was sie lernen müssen wenn sie Assembler lernen, mit der einzigen Ausnahme der Assembler Sprache. Kürzlich habe ich angefangen mich auf diese Gruppe zu konzentrieren. Das Buch " "Write Great Code, Volume One: Understanding the Machine", beschreibt Maschinenorganisation ohne spezifisch Assembler zu lehren. Während jemand der Maschinenorganisation studiert keinen so großartigen Code schreiben wird wie jemand der sich die Zeit nehmt Assembler zu beherrschen, ist meine Hoffnung das jene, die nicht bereit Assembler zu lernen, bereit sind ein Buch wie "Writing great Code" durchzuarbeiten, um so, wenn schon nicht großartigen Code, so doch besseren Code zu produzieren.

Zusammenfassung

Um großartigen Code zu schreiben muss man effizienten Code schreiben. Das Schreiben von Effizienten Code bedarf gute Wahl der Algorithmen und eine gute Umsetzung dieser Algorithmen. Die besten Umsetzungen werden von jenen geschrieben, die Assembler gelernt haben oder die Basisinstruktionen, in die Hochspracheninstruktionen umgesetzt werden, verstehen. Dies bedeutet nicht, das wir zu den Tagen als große kommerzielle Pakete vollständig in Assembler geschrieben wurden zurückkehren sollten. Aber um den Trend von Software langsamer und langsamer zu laufen, obwohl die CPUs ständig schneller werden, umzukehren, bedarf es Programmierer, die die Folgen Ihres Codes auf die Basisinstruktionen abschätzen können.

Selbst wenn Sie nie vorhaben eine einzige Zeile Assembler zu schreiben, ist das Lernen von Assembler und das Denken darin die beste Methode, um zu lernen besseren Code zu schreiben.

Note 1:
Moore's Gesetz sagt das die Semiconduktortechnik die Kapazität bei einem gegebenen Preis alle 18 Monate verdoppelt.
Das Gesetz sagt nichts über Performance. Es sagt nur dass die Anzahl Transistoren sich alle zwei Jahre verdoppelt.

Über den Autor:
Randall Hyde ist der Autor der kürzlichen Veröffentlichungen "Write Great Code" und "The Art of Assembly Language" (beide von No Starch Press), eine der am meisten empfohlenen Quellen über Assembler für Intel-Type Prozessoren. Für HLASM und Mainframeprozessoren gibt es andere Quellen.

Diese Seite ist Mitglied im einem Web-Ring. Sie sind eingeladen die Liste der Mainframe-Liebhaber-Internetseiten zu durchstöbern.		Dinos sind nicht tod. Sie sind am Leben und fühlen sich wohl in einem Rechenzentrum in Ihrer Nähe. Sie sprechen seltsame Sprachen und betreiben Zauberei mit dem Computer. Und falls Sie auf ihr endgültiges Aussterben warten: Dinosaurier waren die Herren der Welt für 155 Millionen Jahren!
Dinos und andere Anachronismen. [ Join Now \| Ring Hub \| Random \| << Prev \| Next >> ]

Nach Großartiger Code geht weiter.
Nach Effizienz ist der Schlüssel.
Nach Bleiben Sie fit.
Nach Lernen Sie Assembler.
Nach Assembler ist nicht tot.
Nach Basis-Instruktionen verstehen.
Nach Zusammenfassung.

Hier finden Sie die Logos unserer Sponsoren und die Logos der Web-Standarts an die sich diese Seite hält.