Wer hatte den Assembler Compiler programmiert?
Der Assembler Compiler ist soweit ich weiß in Maschinencode geschrieben.
Wer war dieser Genie?
Mfg
4 Antworten
"Der erste Assembler wurde zwischen 1948 und 1950 von Nathaniel Rochester für eine IBM 701 geschrieben" - aus https://de.wikipedia.org/wiki/Assembler_%28Informatik%29
Öhm... Den Assembler-Compiler gibt es nicht, es gibt für jede Zielplattform andere Assembler-Dialekte.
Assembler ist außerdem Maschinensprache, wenn wir dieses Beispiel hier mal nehmen
https://de.wikipedia.org/wiki/Maschinensprache#Programmiersprache_C
Dann sieht man in der ersten Zeile, dass der Assembler-Befehl "push rbp" dem Hexadezimalcode "55" (und somit dem Binärcode "1010101") entspricht. Eins zu Eins.
Aber um deine Frage zu beantworten: der erste Assembler geht anscheinend auf ihn hier zurück https://en.wikipedia.org/wiki/Nathaniel_Rochester_(computer_scientist)
Nein. Ein Rechner kann auch mit Assemblersprache noch nichts anfangen, sie muss erst in Maschinensprache umgewandelt werden.
@Tschoo was laberst du? Maschinensprache wäre 010001010 Assembler ist sowas wie MOV 2X sowas in der Art. Das muss auch in reine Maschinensprache compiliert werden... als Softwareentwickler sollte man sowas wissen.
Diese Umwandlung ist völlig trivial, ich würde das nicht mal als "kompilieren" (also "zusammenstellen") bezeichnen. Das ist 'ne einfache Ersetzung. Nochmal:
Wenn der Assembler-Programmierer
>>> mov rbp, rsp
(die zweite Zeile aus dem Wikipedia-Link oben) schreibt, dann ist das hexadezimal
>>> 48 89 E5
bzw. binär
>>> 01001000 10001001 11100101
Und Bamm! Ich hab eben ein kleines Stück sinnvollen Maschinencode programmiert! Hier ist auch noch ein anderes Beispiel Beispiel https://de.wikipedia.org/wiki/Assemblersprache#Beschreibung
Mehr ist das nicht. Das ist die ganze mov-Zeile. Weil die binäre Anweisung aber ziemlich viel Tipparbeit und für den Menschen unverständlich ist und weil die Hexadezimalzahl immer noch für den Menschen unverständlich ist, schreibt man halt den Assembler-Befehl (Mnemonic), der für den Menschen schon deutlich verständlicher ist.
Den Unterschied zur Hochsprache siehst du ebenfalls bei Wikipedia, die C-Anweisung "int main() {" wird in 4 Bytes Maschinencode bzw. in 2 Assembler-Befehle (einmal den 3 Byte-Befehl, den ich oben erklärt habe und dann noch ein 1 Byte-Befehl).
Wenn ein erfahrener Programmier mit zuviel Langeweile sich also eine Tabelle der gängigsten 30-50 Befehle (siehe die Antwort von TeeTier) ausdruckt und sich daneben schreibt, dass z.B. "mov" eigentlich 01001000 ist, dann braucht er nur noch einen Hex- bzw. Binäreditor und dann kann er auch Maschinencode schreiben. Man könnte sich sein Assembler-Programm auch in Word schreiben und am Ende die "suchen & ersetzen"-Funktion nutzen, um das in Maschinencode zu wandeln.
Gängige CPUs haben zwar hunderte von Befehlen, aber wenn man nur die 30 bis 50 wichtigsten kennt, kann man schon fast alles damit programmieren.
Leute die in Assembler programmieren, gucken sich auch gerne mal das Disassemblat an, um zu zu sehen, ob alles korrekt übersetzt wurde. Gerade bei Mikrocontrollern sollte man das hin und wieder mal tun.
Naja, und irgendwann prägt man sich dann die entsprechenden Bytes für die am häufigsten vorkommenden CPU-Instruktionen ein.
Bei mir war das dann früher mal so, dass ich unter DOS einfache COM Dateien direkt im Hexeditor "programmieren" konnte. Natürlich habe ich das nur aus Interesse gemacht, und die Adressberechnungen dabei im Kopf sind extrem fehleranfällig, aber es geht tatsächlich ... wenn auch sehr unkomfortabel. :)
Heute benutze ich dieses Wissen nur noch, um vorhandenen Programmcode in Dateien oder direkt im Speicher zu manipulieren, aber von etwas von Grund auf in reiner Maschinensprache zu entwickeln ist natürlich Quatsch.
Und nebenbei bemerkt ist x86 und x64 Maschinencode ziemliches Wirrwarr. Falls du das wirklich lernen willst, empfehle ich dir führ den Anfang ARM-Maschinencode. Der ist DEUTLICH nachvollziehbarer! :)
Naja, und rein theoretisch könnte man - viel zu viel Freizeit vorausgesetzt - damit auch erst einen primitiven Assembler und im Anschluss damit dann einen rudimentären Compiler für ein primitives C-Subset schreiben. Ersterer wird höchstens einige hundert Byte groß werden, Letzterer vermutlich einige Kilobyte. Und ist man an diesem Punkt angekommen, schnappt man sich das Drachenbuch und implementiert einen ordentlichen Parser, Lexer und was noch sonst alles dazu gehört.
Unterschätze das alles aber nicht! Einen Mini-Assembler in Maschinencode zu schreiben ist nicht sooo leicht, aber auch nicht sooo schwer. Der Mini-C-Compiler im Schritt Zwei dürfte nochmal leichter sein, sofern man keine Ansprüche hat. Der mit Abstand schwierigste und zeitfressendste Punkt kommt danach, wenn man einen "richigen" Compiler für eine ausgewachsene Hochsprache wie C++ schreiben will.
Falls dich das Thema interessiert, du grundlegende Mathematik beherrschst und du auf Low-Level-Spielereien stehst, ist das hier - trotz des hohen Alters - DIE Pflichtlektüre für dich:
https://www.amazon.de/Compilerbau-Tle-Tl-1-Alfred-Aho/dp/3486252941/Dazu gibt es auch noch einen zweiten Band, der unbedingt dazu gehört. Außerdem gibt es mittlerweile noch viele andere schöne Bücher zu dem Thema. Wie gesagt: Stichwort "Compilerbau".
(Falls hier jemand mitliest und Erfahrung auf dem Gebiet hat, bitte mal eine Buchempfehlung in die Kommentare! Mich würde mal interessieren, ob es inzwischen Konkurrenz zum Drachenbuch gibt.)
würde mich interessieren :D lege ich mir villeicht tatsächlich mal zu wenn ich bereit für neue dinge bin :D
Es existiert nicht "der Assambler Compiler", da es unterschiedlichste Assembler Sätze gibt, doch Assambler an sich ist eine sehr simple Sprache und daher ist die Übersetzung selbst ebenfalls sehr simpel. - Den Assamblersatz selbst zu definieren, wie wir ihn heute als z.B. x86 kennen, ist die schwere Aufgabe und das macht auch nicht eine Person.
Prinzipiell richtig. Nur eine Sache stört mich:
Assembler ist keine Maschinensprache sondern sind maschinennahe Sprachen.
(Ob der Kerl aus dem Link unten wirklich der erste war kann ich übrigens nicht bestätigen oder verbessern.)