Diskussion:Assembler
"Assembler" bedeutet meiner Meinung nach nicht zwingend, dass die Maschinenbefehle tatsächlich "direkt von der Hardware" ausgeführt werden. So ist z.B. für Java eine "Virtuelle Maschine" (JVM) mit kompletter "Hardware"-Architektur, Hex-Codes für die Maschinenbefehle usw. definiert, so dass man die JVM auch auf "Assembler"-Niveau programmieren kann (mit "jasm"). Die übliche Implementierung der JVM erfolgt allerdings durch ein Programm, das die Hex-Codes der JVM-Befehle lediglich interpretiert.
Ähnlich war es von gut 25 Jahren mit der "Pascal Micro Engine". Eine damals verbreitete Pascal-Variante - UCSD-Pascal - übersetzte "nur" in einen Byte-Code, der dann von einem anderen Programm "interpretiert" wurde". Anfang der 1980-er gab es aber auch eine Hardware-Implementierung der Pascal Micro Engine (vertrieben von Kontron, wenn ich mich richtig erinnere).
OK, für dieses Wiki ist das vielleicht ein wenig zu spitzfindig, und da ich die Kriterien, wann man von "Assembler" spechen kann oder sollte auch nicht besser auf den Punkt bringen kann, lasse ich das einfach mal als "Diskussion" hier stehen. (Böse Zungen behaupten ja auch, C sei nicht wirklich eine "höhere Programmiersprache" sondern nur ein halbwegs hardware-unabhängiger Assembler :-))
--Martin 22:29, 17. Jun 2004 (CEST)
Also, wenn man die Begriffe Assembler/Interpreter/Compiler nicht sauber unterscheiden kann, desgleichen die Begriffe Quellcode/Zwischencode/Maschinencode, sollte man lieber keine Vorträge darüber halten. :-))))))
W.W. Heinz
Martin hat schon recht damit! Assembler ist meiner Lehrunterlage nach "nur" der Übersetzer von Mnemonics in Opcodes... Das, was der Prozessor später aus seinem Programm-Speicher interpretiert, sind nur noch die Opcodes und deren Parameter. Mit "Prozessor" ist dabei aber nicht zwangsweise nur der in Hardware existierende Prozessor gemeint.
Patrick 09:25, 18. Jun 2004 (CEST)
Hallo Patrick,
danke für die Klarstellung.
Hallo W.W. Heinz,
du bist herzlich eingeladen, mal eine Seite hier in diesem Wiki zu initiieren, die sich mit den Unterschieden und der Abgrenzung dazwischen beschäftigt. Problematisch finde ich nicht das Auseinanderhalten der THEORETISCHEN Begriffe, sondern KRITERIEN dafür setzen, wann man bezogen auf REAL Vorhandenes von dem einen und dem anderen sprechen kann oder sollte.
Heute sind etwa bei Compiler/Interpreter die Grenzen ja fließend. Es gab früher primitive Interpreter, die jedesmal wieder den Quelltext Zeile für Zeile parsen. Typische Technik ist heute jedoch, intern einen Zwischencode zu erzeugen, der dann von einem "Prozessor in Software" (siehe Patricks Anmerkung) ausgeführt wird. Da dieser Zwischencode-Prozessor aber mit dem Interpreter gebündelt ist, spürt der normale "User" davon nichts.
Bei Java ist der "Compiler" und der "Zwischencode-Prozessor" (die JVM) ganz offiziell getrennt. Bei anderen Interpreter-Sprachen gibt es mitunter Tricks, dem Interpreter den Zwischen-Code zu "entlocken" und später zur Ausführung wieder "unterzuschieben", z.B. bei Unix 'sendmail' (eigentlich ein komplexer Makroprozessor, der "nebenbei" auch als MTA fungieren kann). Dann könnte auch noch der (Software-) Prozessor, der Zwischencode ausführt, eine "Just In Time"-Compilierung machen. Einige JVMs tun das, d.h. wenn sie die selbe Sequenz von Zwischencode oft genug gesehen haben, erzeugen sie dafür Maschinenbefehle, bei der Ausführung eines Java-Programms kann man es - abhängig von der JVM - mit einem Mix aus Zwischencode und (nativem) Maschinencode zu tun haben.
Unstrittig ist, dass bei einem "reinen" Assembler eine Nähe der Eingabesprache zu einer (echten oder Pseudo-) Hardware-Architektur besteht, dass also die eigentliche Umwandlung des Quelltextes mehr oder weniger nur eine "1:1"-Abbildung zwischen den Mnemos und den verarbeiteten Op-Codes ist. Aber wo ordnet man Makro-Assembler ein? Leistungsfähige Makrosprachen sind - von den Möglichkeiten, die Sie bieten - höheren Programmiersprachen ähnlich. Aus meiner Großrechner-Zeit erinnere ich mich an ein Makropaket mit dessen Hilfe man nicht nur mathematische Ausdrücke auf einfache Art und Weise in "Assembler"-Programmen verwenden konnte, es gab sogar komplexe Matrizen-Operationen auf einem Level, der deutlich über dem liegt, was beispielsweise C standardmäßig bietet, eher vregleichbar mit generischer Programmierung, so wie sie etwa die Templates von C++ ermöglichen (aber wie gesagt mit Assembler-Makros!).
Schließlich gibt es auch noch "mikroprogrammierbare Prozessoren" in die man für unterschiedliche Zwecke optimierte Mikroprogramme laden kann. Für solche ist dann der Output eines typischen Assemblers nur ein Zwischencode, weil die "real" ausgeführten Befehle ja noch primitiver sind. Und manche CISC-Architekturen sind eigentlich auch mikroprogrammierbare Prozessoren, lediglich mit einem "fest verdrahteten" Mikroprogramm (Western Digitals "Pascal Micro Engine" gehört meines Wissens in diese Kategorie).
Meine Bemerkung, dass ich das auch nicht besser zu formulieren weiß, bezog sich vor allem auf solche Abgrenzungsprobleme vor dem konkreten Hintergrund, dass man für den (vermutlich typischen) Leserkreis dieses Wikis aber auch gar nicht diese Detailtiefe braucht.
--Martin 11:52, 18. Jun 2004 (CEST)
Ich denke auch, daß wir hier unbedingt die Zielgruppe im Auge behalten sollten. Und die Zielgruppe interessiert (IMHO), was ein Assembler ist und wann man ihn wie einsetzen sollte. -- Markus
Schlagt mich, aber ich halte nichts davon, allgemein akzeptierte Fachbegriffe immer wieder in Frage zu stellen und zu zerreden. Das ist unprofessionell, verwirrt Anfänger und führt letztlich zu nichts. Da ist es sicher besser, die Grundbegriffe erst mal richtig zu erklären (und zu kapieren). Dann kann man auch die, zweifellos vorhandenen, Misch- und Übergangsformen richtig einordnen und fruchtlose Diskussionen in der Art von
Ein Sattelschlepper ist ja eigentlich auch eine Lokomotive, bloss ohne Schienen.
erübrigen sich. ;-)
W.W. Heinz
Übrigens, ich habe mir gerade einen Account eingerichtet.
W.W.