|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Wednesday 24. April, 07:09 MES (#1)
|
|
|
|
|
Ich hab mal einen interessanten Artkiel (Quelle leider vergessen) darüber gelesen, daß die meisten Compiler besseren Assember Code erstellen als man von Hand kann.
Außerdem haben C-Treiber schon Vorteile.
Ich hab eine HP 715/80 RISC-Maschine mit Linux laufen. Da ist ein EISA slot drin. Ich hab da tatsächlich eine NE2000 drin zum Laufen gebracht. Mit Assembler Code muß man für jede Architektur neue Treiber schreiben.
Ich finde in den meisten Fällen ist Assembler vergebene Liebesmüh. An gewissen Stellen kann man natürlich erhebluch beschleunigen, aber in der Regel bringts nicht vil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So absolute Sätze wie "besseren Assember Code erstellen als man von Hand kann" sollte man vorsichtig benutzen, denn es wird sich oft genug jemand finden, der die Aussage widerlegen kann :-)
Das wichtige Kriterium an der Sache ist der Zeitaufwand. In Hochsprachen (sogar in C ;) lassen sich Algorithmen einfach schneller aufschreiben.
Ein guter Programmierer könnte wahrscheinlich besseren Code schreiben, allerdings wuerde er dafür eventuell mehrere Tage brauchen und bekäme nur Code fuer seine CPU.
Ein Compiler erzeugt dann halt Code, der x% langsamer ist, braucht dafuer aber nur Sekunden/Minuten und das prinzipiell für alle CPUs.
In den allermeisten Fällen ist es daher allein Zeitökonomisch unsinnig komplexe Sachen in Assembler zu schreiben.
|
|
|
|
|
|
|
|
|
|
|
|
|
Besonders, wenn der Code nicht "write-only" ist, sondern auch noch gewartet werden soll.
Ich erinnere mich noch zu gut daran, wie ich in tausenden Zeilen asm-Code eine short Variable zu einer long Variable gemacht habe. Jede Operation damit mußte geändert werden. In C wäre nur die Definition (short) int x anders.
In Hochsprachen (BASIC, Pascal, C*, Perl, Python, Java...) kann man zudem viel leichter die Quellen als doku heranziehen (mit welcher Formel wird denn die Gravitation im Code berechnet?).
so bleiben dem asm nur die Positionen, die ihm auch heute in Linux schon zukommen: der Bootloader und wichtige low-level Routinen (strncmp, int-handler...)
In keiner Hochsprache habe ich bisher ein Konstrukt für die i8086 Befehle ADC und ROL(RCL) (Addieren mit Übertrag und Rotieren der Bits (mit Übertrag)) gefunden, so daß Code, der diese Features (oder MMX oder sonstewas ununterstütztes) massiv gebraucht, auch mal um den Faktor 3 von asm profitiert.
Bernhard M.
_________
ein jedes Ding, hat seinen Zweck
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 24. April, 11:56 MES (#4)
|
|
|
|
|
Sicher wollte ich nicht behaupten, daß asm überflüssig ist. Im Gegetum. Asm ist von elementarer Wichtigkeit. Jedoch ist der Vorteil, mal abgesehen vom Zeitaufwand, oftmals nicht zu spüren. Bei den heutigen Compilern wird der Code so gut optimiert, daß diese oftmals besser ist, als handgeschrieben. Sicher gibt es Assembler Gurus, die exzellenten asm Code schreiben. Aber im Großen und Ganzen ist kompilerter C Code schon fast optimal.
Siehe zum Beispiel Intel Compiler. Oder der Compaq Compiler für den Alpha. Hochoptimiert.
Natürlich setzt das auch einen optimierten C-Code voraus.
Natürlich verschiebt sich das Problem dadurch nur, aber C ist eben einfacher. (finde ich)
|
|
|
|
|
|
|
|
|
|
|
|
|
Treiber komplett in Assembler zu schreiben ist doch nun wirklich der letzte Schwachsinn: Zu teuer in der Entwicklung, zu teuer in der Wartung, zu fehlerträchtig, nicht portierbar. Btw: Außerdem war doch gerade die Möglichkeit Treiber in -- der für 70er-Verhältnisse -- ausgesprochen portablen Hochsprache C schreiben zu können, die entscheidende Innovation des UNIX-Betriebssystems. Betrachtet man die Portablilität und Stabilität von UNIX-artigen System, hat sich diese Innovation doch bewährt! Warum also, sollte ein halbwegs rational denkender Mensch Treiber wieder in Assembler schreiben wollen, also diesen gewaltigen Rückschritt in die Computersteinzeit vollziehen wollen? Insbesondere wo zumindest der vom gcc3 für x86 erzeugte Maschinencode nur noch wenig Spielraum für Optimierungen läßt. Mit Kenntnis in Optimierungangelegenheiten erfolgreichen Algorithmen stellt sich sowieso die Frage nach der Unwissenheit jener Menschen, die allen Ernstes behaupten, Resourcenbelegungen (Register, Pipelines) besser optimieren zu können, als eine Maschine. Nunja.... Und wenn irgend ein Teilbereich des Codes doch präzisestes nur in Assember erreichbares Timing erfordern sollten, ist erstens sowieso die Hardware scheiße ;-), gibt es zweitens immer noch nach bescheidene __asm__ Schlüsselwort.
|
|
|
|
|
|
