Software::Entwicklung
Übersicht über Assemblercode in freier Software
Steve McIntyre hat für Linaro die Verwendung von Assemblercode in freier Software untersucht. Die Studie diente dazu, die Portierbarkeit auf die ARMv8-Architektur zu untersuchen, und liefert neue Erkenntnisse und Empfehlungen.
Ein signifikanter Teil der Entwicklungsarbeit von Linux auf der ARM-Architektur wird mittlerweile von Linaro geleistet, einem Industriekonsortium, das zahlreiche Entwickler beschäftigt. Auch der ehemalige Debian-Projektleiter Steve McIntyre arbeitet für Linaro und verbrachte einige Wochen damit, eine große Zahl von freien Projekten auf ihre Verwendung von Assemblercode zu untersuchen. Ziele der Untersuchung waren, herauszufinden, ob überhaupt Assemblercode enthalten ist, und falls ja, wofür und ob er überhaupt verwendet wird.
Für die Studie stellten Christian Reis und Matthias Klose eine Liste von Paketen im Ubuntu, Jon Masters und Al Stone eine Liste von Paketen in Fedora zur Verfügung, die potentiell Assemblercode enthalten. Dies ergab 1435 Pakete, deren rohe Ergebnisse in einer Tabelle auf Google Docs festgehalten sind. Eine erste Analyse ergab, dass 10% der Pakete Assembler einsetzen, um atomare Operationen zu ermöglichen. 18,1% haben Code aus anderen Paketen kopiert, 11,1% der Pakete entpuppten sich als Fehlalarme, 38,1% nutzen Assembler für direkte Hardware-Zugriffe, 9,3% enthalten Assembler, der für Linux und seine unterstützten Plattformen nicht relevant ist, 30,4% der Fälle betreffen (vermeintliche) Geschwindigkeitsoptimierungen und 2,9% befassen sich mit dem Zugriff auf Sektionen in ELF-Dateien. Dabei konnte jedes Paket in eine oder mehrere der obigen Kategorien fallen.
Viele Pakete verwenden Assembler für Bitoperationen, oft kopiert aus anderen Projekten, ohne die genaue Funktion zu kennen. Für McIntyre ist das einer der Fälle, wo die Verwendung von Assembler komplett unnötig ist, da die Compiler seit vielen Jahren portable und optimierte Konstrukte dafür bereitstellen.
Auch für die Hardware-Identifikation, beispielsweise CPUID auf x86-Systemen, und den Zugriff auf exakte Zeitstempel wird gerne Assembler eingesetzt, teils aus Mangel an Alternativen. McIntyre hält es für frustrierend, dass es bis heute keine Bibliotheksfunktionen dafür gibt, zumindest keine, die sich allgemein durchgesetzt haben.
Weiter wird Assembler verstärkt zur Nutzung der SIMD-Instruktionen genutzt, was mit MMX, dann SSE, SSE2 und AVX auf x86 begann und auf andere CPU-Architekturen ausgeweitet wurde, z.B. mit NEON für ARMv7. Auch hierfür stellen die Compiler eingebaute Funktionen zur Verfügung, doch diese werden längst noch nicht überall genutzt.
Ähnlich verhält es sich mit Assemblercode, der Synchronisationskonstrukte implementiert, und solchem, der das Verhalten der Gleitkommaeinheit des Prozessors steuert. Dafür stehen Bibliotheksfunktionen zur Verfügung, welche bewährt und korrekt sind und die teils abenteuerlichen Assembler-Konstrukte überflüssig machen.
Auch das Kopieren von Assemblercode aus anderen Projekten kommt vor, mit all den Nachteilen, die das mit sich bringt. Die Duplikation von Code verringert zwar manchmal die Abhängigkeit von externen Projekten, kopiert aber auch Fehler oder gar Sicherheitslücken mit, die dann nicht behoben werden. In einigen Fällen betrifft das Code aus zlib oder libjpeg, wo das Kopieren völlig unnötig ist.
Zusammenfassend findet McIntyre, dass die meisten Entwickler die eingebauten Methoden von GCC kennen und sie auch nutzen. In einigen Fällen nutzen die Entwickler noch Assemblercode als Notlösung, wenn der Code mit einem weniger leistungsfähigen Compiler gebaut wird, doch das sollte keine Linux-Distribution betreffen. Wo Assemblercode noch vorhanden ist, beginnen die Entwickler oft mit seiner Eliminierung, was die Portabilität verbessert. Auf der anderen Seite existiert eben noch älterer Code mit kopiertem oder auf der Basis von nicht mehr gültigen Annahmen entwickeltem Assembler, der mitunter auf mangelnde Wartung der Pakete hindeutet. Insgesamt sind aber weniger als 6% der Pakete aus den Fedora- und Ubuntu-Archiven betroffen. Kurios ist das Vorhandensein von VAX-Assembler in einigen Paketen. In anderen Paketen wurde Assemblercode zwar eingebaut, aber danach auskommentiert und darf somit als Fehlalarm gelten.
Für die Portierung von Software auf die neue 64-Bit-ARM-Architektur gilt daher, dass die meisten Paketen problemlos laufen werden; einige werden trotz Assemblercode laufen, weil bereits der passende Code vorhanden ist; einige andere werden ohne spezielle Maßnahmen nicht mit voller Geschwindigkeit laufen oder auf einzelne Funktionen verzichten müssen. Bei einigen CPU-intensiven Anwendungen wie Multimedia und Kompression könnten manuelle Optimierungen in Assembler angebracht sein, abgesehen davon hat Assembler laut McIntyre wenig Sinn und sollte vermieden werden.
