Diskussion:Gegenüberstellung Assembler und Hochsprache - Versionsgeschichte

PicNick am 13. Dezember 2005 um 14:28 Uhr

2005-12-13T14:28:35Z

PicNick am 13. Dezember 2005 um 14:27 Uhr

2005-12-13T14:27:58Z

SprinterSB_alt am 13. Dezember 2005 um 13:38 Uhr

2005-12-13T13:38:33Z

Frank am 13. Dezember 2005 um 12:30 Uhr

2005-12-13T12:30:04Z

PicNick am 13. Dezember 2005 um 11:19 Uhr

2005-12-13T11:19:42Z

SprinterSB_alt am 8. Dezember 2005 um 13:51 Uhr

2005-12-08T13:51:41Z

SprinterSB_alt am 8. Dezember 2005 um 11:26 Uhr

2005-12-08T11:26:38Z

Frank am 8. Dezember 2005 um 09:41 Uhr

2005-12-08T09:41:56Z

Frank am 8. Dezember 2005 um 09:41 Uhr

2005-12-08T09:41:11Z

PicNick am 8. Dezember 2005 um 08:48 Uhr

2005-12-08T08:48:46Z

@@ Zeile 126: / Zeile 126: @@
 *+ alles liegt in der Hand des Programmieres
 *- alles liegt in der Hand des Programmieres
 --PicNick 15:27, 13. Dez 2005 (CET)

← Nächstältere Version		Version vom 13. Dezember 2005, 14:27 Uhr
Zeile 121:		Zeile 121:

	--[[Benutzer:SprinterSB\|SprinterSB]] 14:38, 13. Dez 2005 (CET)		--[[Benutzer:SprinterSB\|SprinterSB]] 14:38, 13. Dez 2005 (CET)
		+
		+	Bei solche +- Listen ist man halt immer auf dem Glatteis. Ohne den Bedarf und Vorkenntnis zu kennen, ist es schwer, irgendwas als Vor- oder Nachteil zu sehen. Was ist besser:Ein Nagel oder eine Schraube ?<br>
		+	Grad beim Assembler kannst du jede x-beliebige Eigenschaft bei plus und minus gleichzeitig hinschreiben
		+	*+ alles liegt in der Hand des Programmieres
		+	*- alles liegt in der Hand des Programmieres
		+
		+	--PicNick 15:27, 13. Dez 2005 (CET)

← Nächstältere Version		Version vom 13. Dezember 2005, 13:38 Uhr
Zeile 110:		Zeile 110:

	--[[Benutzer:Frank\|Frank]] 13:30, 13. Dez 2005 (CET)		--[[Benutzer:Frank\|Frank]] 13:30, 13. Dez 2005 (CET)
		+
		+	----
		+	HS ist ja nicht HS: C aus Perspektive einer modernen, objekt- oder askektorientierten Sprachen ist eher so was wie ein portierbarer Assembler. Und ob die HS wie z.B. Java unter einer VM läuft oder nativ übersetzt und statisch gelinkt wurde, ist nicht gerade ein kleiner Unterschied. Mag C für kleinere µC durchaus sinnvoll sein, so ist das für Java nur noch sehr bedingt bis gar nicht mehr gegeben.
		+
		+	Das Problem mit dem Makro-Debug kommt aus der Praxis. Dass ein Makro korrekt expandiert, bedeutet noch nicht, dass der Code, der letztendlich zur Ausführung kommt, ok ist. Makros sind in der Quelle recht gut lesbar. Das gleiche Makro kann an verschiedenen Stellen im Code stehen, verschachtelt sein und Parameter haben, die weitergereicht werden. Durchquert man Debuggen durch fehlerhaften Code ein Makro, dann sieht die Quelle ziemlich wüst aus, und man blickt kaum noch, in welchem Code das resultiert und was ab geht. Solche Konstrukte sollte man also tunlichst vermeiden, auch wenn's in der Quelle nett aussieht und evtl besseren Code ergibt als Funktionsaufrufe.
		+
		+	Diese Seite ist ja "nur" eine Diskussion, wo unterschiedliche Standpunkte/Aspekte/Meinungen/Erfahrungen diskutiert werden und deren Ergebnisse evtl in aufbereiteter Form in den dazugehörenden Artikel übernommen werden. Daß Leser eines Artikel nicht mit Diskussionen belämmert werden, dafür gibts ja immer Diskussions-Seiten, bzw Benutzer-Diskussionen.
		+
		+	Als eigenständiger Artikel ist ne trockene Tabelle allein nicht mehr so toll. Wem der Artikel nützt, weiss ich nicht. Vielleicht jemand, der anfängt und sich entscheiden will, welche Sprache er nimmt oder überhaupt Assembler was ist. Oder mit dem Gedanken spielt, umzusteigen. Als eigener Artikel kann auch dazugetextet werden oder Punkte in der Tabelle kommentiert werden.
		+
		+	--[[Benutzer:SprinterSB\|SprinterSB]] 14:38, 13. Dez 2005 (CET)

← Nächstältere Version		Version vom 13. Dezember 2005, 12:30 Uhr
Zeile 104:		Zeile 104:

	Is immer angenehm, mit vernünftigen Leuten zu diskutieren.<br>Bei meinem Postulat, daß Assembler nicht zwangsläufig schneller oder sonstwas ist, hab ich tatsächlich implizit die Kombination Assembler / Programmierer gemeint.<br>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.		Is immer angenehm, mit vernünftigen Leuten zu diskutieren.<br>Bei meinem Postulat, daß Assembler nicht zwangsläufig schneller oder sonstwas ist, hab ich tatsächlich implizit die Kombination Assembler / Programmierer gemeint.<br>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.
		+
	----12:19, 13. Dez 2005 (CET)PicNick 12:19, 13. Dez 2005 (CET)		----12:19, 13. Dez 2005 (CET)PicNick 12:19, 13. Dez 2005 (CET)
		+
		+	Was die Anmerkung von Sprinter zu dem Makro debuggen betrifft, so mag es sein das das aufwendig ist. Aber darum gings eigentlich nicht. Ein Makro oder Codeblock wird nur ein einziges mal richtig ausgetestet, warum sollte man die später nochmals debuggen? Wir sollten bei der Diskussion die Realitäten und Praxis nicht aus dem Augen verlieren. Wem soll der Artikel oder Vergleich helfen? Daher sollte man sich nicht in der Theorie verlieren!
		+
		+	--[[Benutzer:Frank\|Frank]] 13:30, 13. Dez 2005 (CET)

← Nächstältere Version		Version vom 13. Dezember 2005, 11:19 Uhr
Zeile 102:		Zeile 102:
	btw: durch verschachtelte Makros zu debuggen ist ebenso keine Freude, ebenso nachzuvollziehen, was sie eigentlich tun, wenn man die nach Quellcode auflöst...		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.<br>Bei meinem Postulat, daß Assembler nicht zwangsläufig schneller oder sonstwas ist, hab ich tatsächlich implizit die Kombination Assembler / Programmierer gemeint.<br>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.
		+	----12:19, 13. Dez 2005 (CET)PicNick 12:19, 13. Dez 2005 (CET)

@@ Zeile 95: / Zeile 95: @@
 '''Ergänzungen'''
 * +HS: bringt evtl workarounds für hardbugs mit
 * -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.
 --[[Benutzer:SprinterSB|SprinterSB]] 12:26, 8. Dez 2005 (CET)
 ----

← Nächstältere Version		Version vom 8. Dezember 2005, 11:26 Uhr
Zeile 42:		Zeile 42:

	--[[Benutzer:Frank\|Frank]] 10:41, 8. Dez 2005 (CET)		--[[Benutzer:Frank\|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 [[Benutzer:PicNick\|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 [[Benutzer:PicNick\|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 "<code>if</code>" gehören zum Sprachumfang, Funktionen wie zB "<code>printf</code>" 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:
		+	<pre>
		+	; 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
		+	</pre>
		+	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 <code>nop</code> (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: 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.
		+
		+	--[[Benutzer:SprinterSB\|SprinterSB]] 12:26, 8. Dez 2005 (CET)
		+	----

@@ Zeile 35: / Zeile 35: @@
 BTW: Ich hab mich verstickt in Diskussionsseite Artikel-Autor, ich werd' mich bessern
----09:46, 8. Dez 2005 (CET)
+--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.

← Nächstältere Version		Version vom 8. Dezember 2005, 09:41 Uhr
Zeile 36:		Zeile 36:

	---09:46, 8. Dez 2005 (CET)		---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.
		+
		+	--[[Benutzer:Frank\|Frank]] 10:41, 8. Dez 2005 (CET)

@@ Zeile 32: / Zeile 32: @@
 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.
 ---09:46, 8. Dez 2005 (CET)