Diskussion:Gegenüberstellung Assembler und Hochsprache: Unterschied zwischen den Versionen

Version vom 13. Dezember 2005, 12:19 Uhr

Gegenüberstellung_Assembler_und_Hochsprache

Ich bin nicht ganz glücklich mit den Argumenten bei Vor- und Nachteilen. Mir scheint einiges davon sehr subjektiv und entspricht doch ziemlich den gängigen Klischees.

Beispiele, was ich meine: Assembler ist keinesfalls automatisch der schnellste /kleinste Code, nur weil es Assembler ist Inwiefern ist Assembler fehleranfällig oder schwer zu debuggen ?

Hochsprache: Es ist kein Nachteil, daß ich mit dem generierten Maschinencode nix zu tun habe, sondern der Grund, warum sowas verwende (Weil ich mich an dem "Problem" und nicht der "Maschine" orientiere)

Wie sehen das andere ?

---PicNick 17:13, 7. Dez 2005 (CET)

Ich hab deinen Diskussionsbeitrag mal hier hin kopiert, weils ja diesen Artikel betrifft. Verstehe nur die Kritik nicht, ich dachte es ist Dein Beitrag?

--Frank 20:19, 7. Dez 2005 (CET)

So, nun hab ichs mal durchgelesen, kann nun meine Meinung dazu abgeben. Ich finde eigentlich man kann mit der Darstellung leben. Ich finde schon das Assembler fehleranfälliger ist und im Vergleich zu einer Hochsprache auch schon schwerer zu debuggen auch wenn die Tools heute alle leistungsfähiger geworden sind.

Die Wahrscheinlichkeit das manuell geschriebener Assemblercode etwas kompakter ist, würde ich auch nicht unbedingt abstreiten. Bei schlechten Programmierern kanns natürlich auch umgekehrt sein, aber bei gutem eigentlich nie.

Das man bei der Hochsprache nix mit dem generierten Code zu tun hat ist eigentlich schon ein Vorteil. Allerdings gibts auch Ausnahmesituationen wo man etwas optimieren möchte und da wäre es schon ganz schön wenn man wüsste was genau generiert wurde.

--Frank 21:12, 7. Dez 2005 (CET)

Die Vergleichstabelle hat der Sprinter ursprünglich beim Assembler reingestellt. Sie ist ja nicht so falsch, daß ich unbedingt sofort was ändern müßte, aber eben recht subjektiv gefärbt, (Fehleranfällig ist der User, nicht der Assembler, und schwer zu debuggen nur für Ungeübte) Diese meine Meinung kommt vielleicht davon, daß ich ca. 10 Jahre System-programmierung mit Assembler auf DOS, VMS und Siemens hinter mir habe und daher eine bißchen diffenerziertere Einstellung. Egal, lassen wir's, in dieses Detail werden wir uns nicht verbeissen.

BTW: Ich hab mich verstickt in Diskussionsseite Artikel-Autor, ich werd' mich bessern

--PicNick 09:46, 8. Dez 2005 (CET)

Ein bisschen Subjektiv wirds immer eingefärbt sein. Wenn Du es mit deinen Assembler Augen siehst, wird´s in die andere Richtung eingefärbt ;-) So stark eingefärbt find ich´s aber eigentlich garnicht. Sicher liegen die Fehler immer beim Programmierer, aber ein Compiler (Hochsprache) hat mehr Möglichkeiten Fehler abzufangen. Schon von der Syntax her können in Assembler schnell Dreher reinrutschen die beim assemblieren nicht erkannt werden. Zudem müssen in Assembler für die gleiche Aufgabe viel mehr Codezeilen geschrieben werden, die Wahrscheinlichkeit eines Fehlers geht schon statistisch nach oben. Das "schwer Debuggen" müsste man vielleicht umtaufen in "schwerer zu debuggen". Auch da trifft oberes zu. Eine Aufgabe läßt sich in einer Hochsprache vielleicht in 10 Zeilen erledigen, in Assembler braucht man nicht selten dann 100 - 500 Zeilen. Schon da ist ersichtlich das das Debuggen mehr Zeit beansprucht, somit schwerer ist. Erfahrene Programmierer nutzen natürlich mit der Zeit Makros und viele getestete Codeblöcke, dadurch werden diese Nachteile dann wieder etwas ausgeglichen.

--Frank 10:41, 8. Dez 2005 (CET)

In einem gesonderten Artikel kann man das Thema natürlich ausführlicher darstellen und die Tabelle kommentieren.

Zu +Assembler

Für jedes Programm in einer beliebigen Hochsprache gibt es ein Maschinenprogramm, das mindestens genauso schnell ist und mindestens eines, das nicht länger ist. Momentag gehe ich mal davon aus, daß Asm 1:1 nach Maschinen-Code übersetzt wird. Ob ein Assembler-Programmierer (ASP) diesen Code überhaupt findet bzw. einsetzen möchte ist was anderes, das ist nicht der gewählten Technologie anzulasten.

Umgekehrt gibt es nicht für jedes Asm-Programm, das eine (lösbare) Aufgabe optimal löst, ein Hochsprachen-Programm, das -- nachdem es übersetzt wurde -- echt bessert ist (echt im Sinne von echt kleiner/schneller) und die gleiche Aufgabe löst/überhaupt schafft. Damit hat man die Abschätzung

Asm [math]\le[/math] Hochsprache

jeweils einmal was Größe, und einmal, was Platz angeht (können unterschiedliche Asm-Programme sein, die das erfüllen).

Zu +Hochsprache (besser zu debuggen)

Ein Hochsprachen-Programmierer (HSP) kann in der HS debuggen. Zusätzlich hat er in vielen Debuggern die Möglichkeit, eine zweite Debug-Ebene zu nutzen: Debuggen des Asm. Dieser zusätzliche Ebene erleichtert u.U. die Fehlersuch. Andererseite ist es fraglich, ob man dieses + überhaupt der HS zuschlagen sollte, weil man sich ja auf Asm-Ebene begibt.

Ein HS-Debugger kann komplexe Datentypen und Komposite darstellen, und Pointer dereferenzieren. Ein Asm-Debugger hat keine Vorstellung von den Datentypen. Der ASP muss also immer wissen, wie ein Datum zu interpretieren ist (jau, ein HSP muss das auf seiner Ebene auch... ;-))

Trotzdem geb ich PicNick recht. Der entsprechende Punkt ist nicht haltbar. Es ist ein absolutes Greuel, nen agressiv optimierten HS-Code zu debuggen. (ich nenn hier nur mal inlining, reverse inlining, loop unrolling, instruction scheduling, common subexpression elimination, etc). Es gibt u.U. keine eindeutige Zuordnung mehr zwischen Quelle und Asm bzw. Maschinen-Code, die Reihenfolge hat sich geändert (Instruktionen, Blöcke, ...) etc, oder der HS-Code hat überhaupt keine Entsprechung mehr.

Zu -Hochsprache (Unsicherheit wie Code aussieht)

Das von PicNick gegebene Argument ist zutreffend, widerspricht aber IMHO nicht dem Gesagten. Mit einem HS-Programm will der HSP etwas bestimmtes erreichen. Um bestimmte Aufgaben auf der Zielhardware zu erledigen, muss die Hardware in einer bestimmen Art und Weise bedient werden. Tut man das nicht, hat man ein Problem.

Dazu folgende Anmerkung: Es ist zu unterscheiden zwischen einer HS und zusätzlichen Funktionalitäten, die zB in einer Bibliothek zur Verfügung gestellt werden. Befehle wie "if" gehören zum Sprachumfang, Funktionen wie zB "printf" in C tun es nicht.

Die Misslichkeit, keine volle Kontrolle über den erzeugten Code zu haben, illustriert folgendes Beispiel:

Angenommen, morgen wird ein Hardware-Fehler (silicon bug) der betrachteten MCU/CPU bekannt und veröffentlicht. Diesen will man umschiffen, was durch Einhaltung bestimmer Restriktionen erreichbar ist. Beispiel:

; der kaputte Befehl, oft ganze Sequenzen mit Vorgeschichte
; oder ein Befehl mit Nebeneffekten
r0 := 0                       ; 0 nach r0 tut nicht (nur) was es soll

; workaround 1
r0 := 1                       ; 1 nach r0
r0 := r0 - 1                  ; 1 abziehen von r0

; workaround II
r0 := r0 XOR r0               ; das ist immer 0

Dabei sollen das echte Instruktionen auf einer gedachten Maschine sein und keine Pseudo-Instruktionen (etwa bei AVR, wo "clr r0" identisch ist mit "eor r0, r0").

Die Frage: Schafft man es in der HS, so was zu garantieren? Mit Asm geht das ohne Frage.

Weiteres Beispiel wäre die Aufgabe, einen Bootloader in der HS zu schreiben oder ein Hochsprachenprogramm, das ein nop (no operation) abgebildet wird.

In einer HS ist man also immer irgendwie "festgenagelt". Klar ist auch, daß nicht alle denkbaren Problemstellungen, die eine bestimmte Bedienung der Hardware erfordern, durch den Sprachumfang inklusive eventueller Bibliotheken (oft in low level implementiert) abgedeckt sind. Mit Asm bzw in Maschinen-Code hat man diese Abdeckung.

Ergänzungen

• +HS: bringt evtl workarounds für hardbugs mit
• +HS: ja nach HS werden Ausnahmen abgefangen und einer definierten Behandlung zugeführt
• -HS: HS-Compiler sind oft wesentlich komplizierter aufgebaut als Assembler und enthalten durchaus Fehler. Auch Assembler können Fehler enthalten, aber wegen der einfacherern Struktur sind sie dort seltener zu erwarten und anzutreffen -- was die Praxis zeigt. Mit "Fehler" ist hier nicht gemeint, daß das Transformationsprogramm abstürzt, sondern daß es falschen Code erzeugt.

--SprinterSB 12:26, 8. Dez 2005 (CET)

btw: durch verschachtelte Makros zu debuggen ist ebenso keine Freude, ebenso nachzuvollziehen, was sie eigentlich tun, wenn man die nach Quellcode auflöst...

Is immer angenehm, mit vernünftigen Leuten zu diskutieren.
Bei meinem Postulat, daß Assembler nicht zwangsläufig schneller oder sonstwas ist, hab ich tatsächlich implizit die Kombination Assembler / Programmierer gemeint.
Die Frage, wieweit eine HS im Zusammenhang mit MikroKontrollern überhaupt gerecht beurteilt werden kann, stell ich einfach mal in den Raum. Das, wofür ich eine HS verwende, also die Abtrennung meines Problems von der Hardware, kann ich bei Mikrokontrollern oft ja garnicht so brauchen.