Sonntag, 18. Mai 2008

Ein Assemblerprojekt

Bereits vor längerer Zeit fasste ich den Plan zu einem Assemblerprojekt. Das Ziel war und ist, den - bislang in Java implementierten - niedriggenauen Ephemeridenrechner durch eine Assembler-Bibliothek zu ersetzen. Für den Preis bloss bogenminutengenauer Planetenpositionen und natürlich der Plattformabhängigkeit winkt ein extrem hoher Geschwindigkeitsvorteil. Wozu ist das nützlich? Zum Beispiel für GUI-Komponenten von Astrologieprogrammen, in denen man mittels "Drag and Drop" einzelne Planeten auf andere Positionen oder in Kontakt mit anderen Planeten bringen kann. Hier ist es nötig, während des Ziehvorgangs möglichst schnell die Planetenposition zu ermitteln, wobei jedoch Bogenminutengenauigkeit voll ausreicht. Beim "Drop"-Event, vor dem Hinschreiben der neuen Stände, kann dann ja die vom Benutzer letztlich gewählte Position noch einmal in grösserer Genauigkeit errechnet werden.

Nach ersten Vorstössen in diese Richtung musste ich dieses Assemblerprojekt leider einige Jahre liegenlassen. Nun komme ich noch einmal darauf zurück und plane, meine Lernschritte in diesem Blog aufzuzeichnen. (Ich habe vor vielen Jahren auf meinem C64 in der 6502-Assemblersprache programmiert, habe jedoch in jüngerer Zeit keine Programmiererfahrungen mit Assembler mehr.)

Ich beginne mit einigen allgemeinen Gedanken zur Assemblerprogrammierung.

Meine ursprüngliche Faszination für Java war 2004 bereits abgeebbt und dem üblichen Ärger über das jar-Chaos und die oft viel zu umständliche Sprache gewichen (man denke exemplarisch an den Zoo der verschiedenen "Writer": bevor eine Ausgabe auf eine bestimmte Weise gemacht werden kann, muss erstmal eine Handvoll verschiedener Writer-Objekte instanziiert und ineinander verkettet werden). Auch die Plattformunabhängigkeit war schliesslich kein Totschlagargument mehr. Es gibt plattformunabhängige Alternativen wie Perl oder Ruby. Auch C/C++ kann man als plattformübergreifend betrachten, denn es gibt auf jeder Plattform Compiler und darüberhinaus ein genormtes Vorgehen zur Herstellung der Binaries (Makefiles).

Aber Assembler? Das ist ein frecher, geradezu unverschämter Verstoss gegen die Plattformunabhängigkeit - wie kann man denn heute noch freiwillig in Assembler programmieren? Aber da ich Unverschämtheiten manchmal durchaus reizvoll finde, war das allein schon Grund, mich diesem Thema zuzuwenden. Natürlich meldet sich sofort das programmierparadigmatische Über-Ich: "Ja aber denk' doch mal an die Plattformunabhängigkeit", "Was machen denn die armen Leute, die einen anderen Prozessor haben als du?". Die gucken dann eben in die Röhre! Manchmal muss der Forscherdrang höher bewertet werden als moralische Bedenken (zumindest gilt dies für Werte wie Plattformunabhängigkeit). Und so darf ich mir auch mal das Vergnügen gönnen, ein Assemblerprojekt durchzuführen. Kunde bin erstmal ich selbst. Wer sonst noch von dem Projekt profitieren will, braucht eben einen x86er, einen Celeron oder so etwas, wie ihn handelsübliche Windows-Rechner bis heute enthalten.

Assembler - das bedeutet: Keine Nanosekunde Rechenzeit und kein Byte des Hauptspeichers wird sinnlos verschwendet. Die Abhängigkeit von anderen Produkten beschränkt sich auf den Mikroprozessor und die Windows API - und selbst letztere wird nur für Ein- und Ausgaben benötigt und ist daher nicht zwingend (wenn wir beispielsweise eine DLL programmieren, die nur von anderen Programmen aufgerufen wird, kann es sein, dass überhaupt kein Dialog und kein Filezugriff zu programmieren ist). Assembler ist die auf die Spitze getriebene Hybris. Der Assemblerprogrammierer kann alles besser als die anderen und traut keinem anderen Softwareprodukt. Den vorgedachten Befehlssatz eines Mikroprozessors muss er wohl zähneknirschend akzeptieren, doch nichts, was darüber hinausgeht. Er wünscht auch keine IDE, die ihm auf Knopfdruck nicht nachvollziehbaren Code generiert, also um des vermeintlichen Entwicklerkomforts willen das Programm für alle User um Bytes und Nanosekunden vermehrt.

In Assembler zu programmieren, weckt Erinnerungen an die Zeiten des programmierbaren Taschenrechners (TI57 und Konsorten) - nur liegen die Taktzyklen im Nano- statt im Millisekundenbereich. Das ist reizvoll.

Ich behaupte: Assembler, die Ursprache aller Programmiersprachen, ist für jeden Entwickler eine gute Übung. Denn Hybris gehört, wie wir von Larry Wall wissen, zu den wertvollsten Tugenden des Entwicklers (neben Faulheit und Ungeduld).

Keine Kommentare :