Forum

Hallo!

Ich versuche gerade, den Prozess zu verstehen, wie aus einem in einem Texteditor geschriebenen Programm eine Menge von elektrischen Signalen wird, die der Prozessor versteht.


Wenn ich ein Programm in Assembler schreibe und es speichere (ohne zu kompilieren), dann ist das ja nur eine Textdatei. D. h. da sind magnetische Muster auf der Festplatte, die dann in elektrische Signale umgewandelt werden (Bitmuster), und einige dieser Bitmuster werden beim Öffnen der Datei über die Zeichensatztabelle (z. B,. ASCII) bestimmten Fonts zugeordnet und dann am Bildschirm angezeigt. Das heißt, die Bitmuster repräsentieren Dezimalzahlen, die Zeichen zugeordnet sind.

Aber: Wenn ich die dann kompiliere und linke usw. wird daraus eine exe-Datei. die enthält Maschinencode. Wenn ich die in einem Texteditor öffne, passier genau dasselbe wie bei der .asm-Datei.

Was aber passiert, wenn ich die Datei ausführe? Wie kann es sein, dass die CPU etwas wie "move x,y", was ja eine Folge von Zeichen ist, in eine Reihe von elektrischen Signalen umwandelt?

ich lese da immer, dass "move x,y" für einen bestimmten Maschinenbefehl steht, der dann 0010100101010 lautet und hexadezimal 65 F3 11 oder sowas. Aber 0010100101010 ist ja nur die Repräsentation von Bitmustern als Zeichen. Wenn ich eine Datei schriebe, in der nur 0110101010110101 usw. steht, dann wird das ja nicht automatisch von der CPU als Befehle erkennt, sondern nur als eine Reihe von 0 und 1.

Z. B. das hier:

XOR CL, [12H] = 00110010 00001110 00010010 00000000 = 32H 0EH 12H 00H

Von der Wiki-Seite:
http://en.wikibooks.org/wiki/X86_Assembly/Machine_Language_Conversion

Da steht auch "The opcode for XOR is "001100dw"" Ich verstehe das nicht. 001100dw ist doch nur eine Folge von Zeichen? Da muss doch eine Reihe von elektrischen Signalen dahinterstecken? Wie ist denn "XOR" mit den elektrischen Signalen verbunden?

Wäre super, wenn mir da jemand etwas Klarheit verschaffen könnte.

Danke!

Hi,
eines hast du schon richtig verstanden:
Die Textdatei selber ist noch nicht der ausführbare Code, den die CPU wirklich abarbeiten kann.


Das Zauberwort ist hier die Toolcain - die Abfolge und der einsatz bestimmter Werkzeuge in verbindung mit dem Lader und dem Scheduler bei der Ausführung.


Am Anfang eines Programmes steht die Idee und die Beschreibung des Verhaltens. Danach erfolgt die Strukturierung und verfassen des Programmtextes in einer Programmiersprache (C, Java, Fortran, Basic, Brainfuck, etc.)
Dieser Text wird dann von einem Compiler in 2 hälften zerlegt und zu einem Maschinen-Code-Modell wieder zusammengebaut (Objekt-Code oder Assembler).
Aus den beiden Teilen (Speichermodell und Ablaufmodell) wird dann in der endgültigen Übersetzung im Assembler der von Dir gezeigte Maschinen-Code, der dann auf der Zielhardware und nur dort abläuft, da die Bitfolgen nur von einer bestimmten CPU-Klasse abgearbeitet werden kann (Steuerungsmatrix).
Auf einem Mikrokontroller kann dann dieser Maschinencode direkt mit einem Brennprogramm oder einem Flash-Programmiergerät geladen und nach dem nächsten Reset ausgeführt werden.
Auf einem komplexen Rechner (z.B. PC mit Windows oder Linux-Betriebsystem) muß die Datei mit dem Code in sich noch etwas strukturiert werden, damit die verschiedenen Teile vom Binder-Lader-Modul in den Hauptspeicher an eine bestimmte Stelle kopiert und danach die Kontrolle dort hin übergeben werden kann. Auf einem Komplexen Rechner sorgt das Betriebsystem und dort der Scheduler für die Ausführung des Binärcodes in der CPU.


Texteditor-(Programming-Suite)- Compiler - (Assembler) - Binder - Lader - Scheduler

Ach ja - der wesentliche Teil ist die Steuerungsmatrix.

Auf der CPU ist jede Funktion mit so genannten Gattern als ALU (Artthmetische-Logische-Steuereinheit) aufgebaut.
in den Bitfolgen werden dann die Gatter (Gates - Tore) der ALU auf und zu-Gesteuert (vereinfacht gesagt), so daß die Daten in den geforderten Berechnungswegen durch die ALU laufen und dabei die Ergebnisse erzeugt werden.

Die ALU steuert dabei die Berechnung der gewünschten Ergebnisse, die Adressierung und Referenzierung der zu verwendenden Daten und die Verwaltung des Programmablaufes (bedingte Sprünge im Ablauf).
Die Steuerungsmatrix, in die jede Bitfolge zu beginn eines Ausführungsschtittes eingelesen wird, nimmt die Reihenfolge der Ansteuerungen und das fortschreiten der Berechnung vor. Zum Abschluß wird jeweils der nächste Bit-Code referenziert, der dann in die Steuerungs-Matrix aufgenommen wird.

» Ach ja - der wesentliche Teil ist die Steuerungsmatrix.
»
» Auf der CPU ist jede Funktion mit so genannten Gattern als ALU
» (Artthmetische-Logische-Steuereinheit) aufgebaut.
» in den Bitfolgen werden dann die Gatter (Gates - Tore) der ALU auf und
» zu-Gesteuert (vereinfacht gesagt), so daß die Daten in den geforderten
» Berechnungswegen durch die ALU laufen und dabei die Ergebnisse erzeugt
» werden.
»
» Die ALU steuert dabei die Berechnung der gewünschten Ergebnisse, die
» Adressierung und Referenzierung der zu verwendenden Daten und die
» Verwaltung des Programmablaufes (bedingte Sprünge im Ablauf).
» Die Steuerungsmatrix, in die jede Bitfolge zu beginn eines
» Ausführungsschtittes eingelesen wird, nimmt die Reihenfolge der
» Ansteuerungen und das fortschreiten der Berechnung vor. Zum Abschluß wird
» jeweils der nächste Bit-Code referenziert, der dann in die
» Steuerungs-Matrix aufgenommen wird.

Okay, super, das ist schon mal sehr informativ!

Aber wie genau läuft der Schritt von Assembler zu Maschinencode ab?

Angenommen ich schreibe mov al, 9h

Daraus muss ja irgendwie eine Bitfolge werden, die sich hexadezimal als z. B. B4 C8 darstellen lässt.

Wie macht der Assembler das? Ersetzt der einfach jedes Mov durch B4?

Und wenn ich dann eine Hex-Datei habe, die ich im Hex-Editor anschauen kann. Wie werden daraus dann elektrische Signale?

Was bedeutet es, wenn ich direkt in Maschinensprache programmiere? Mache ich dann eine Textdatei auf und schreibe lauter 010101 rein und das wars dann? Weil die 0 die ich da reinschreibe, die entspricht ja nicht einem 0V sondern dem ASCII-Code 30 (hexadezimal)...

Der Teil vom Assembler in Maschinenbefehle, den kapier ich noch nicht.

Du kannst die Mnemonic auch selbst schreiben.

Das machst, indem du aus dem Datenblatt die Befehle mit den entsprechenden HEX-Codes in eine Tabelle mal herausschreibst.
Auch die Addressierungsarten musst herausschreiben und dekodieren.
Das geht alles händisch.

Hier im Beispiel mit dem 6809 von Motorola:
http://www.lomont.org/Software/Misc/CoCo/Lomont_6809.pdf

Das ist wie eine Landkarte mit Koordinatensystem....

Dann macht !DU den Assembler, indem du' die richtige Syntax schreibst für den jeweiligen Befehl.
Befehl für Befehl, mit' den Register Adressierungen händisch dekodiert schreibst.

Hast du alles - das Programm - für deine Anwendung auf zB Papier geschrieben.
Dann kannst daran gehen, die einzelnen HEX-Werte in ein PROM; besser EPROM zu brennen.
Ein EPROM ist hier besser, weil, wenn du Programmfehler haben solltest, kannst es wieder löschen und neu beschreiben.

Das Programmiergerät ist auch was "watscheneinfaches".
Es ist nix anderes, als ein Adressszähler, bei denen du dann bei der eingestellten Adresse die Daten
(zB mit Dip-Schalter umgeschaltet) den HEX-Wert auf den Datenbus anlegt,
dann machst mit der "Programmier-Taste" -"Zapp!"
Eine passende Hochspannung von gegebener Schaltzeit "bruzelt"
daraufhin diesen HEX-Wert in diese Adresse im EPROM-Speicher.

Ein Programm für einen µProzessor, oder µController beginnt normal mit einem Sprungbefehl zu den Hardware --> Reset-, bzw. Interrupt_Adressen.
Auf diesen Adressen liegt normal ein Sprungbefehl - "springe zu Reset_Bearbeitungsroutine"; bzw. "Interrupt_Bearbeitungsroutine"....
Das sind die wichtigsten Eingangsleitungen zum Prozessor/Controller.
Diese werden auch benötigt, um den Start vom Anlegen der Versorgungs-Spannung zum vollen Betrieb geordnet durchführen zu lassen.

So in etwa geht das zu Fuss-Programmieren.

In diesem Fall musst! du den Prozessor und dessen
angeschlossenen Bausteine -Interfaces genau kennen!
Musst zB wissen, was die ALU macht, was der Programm-Zähler macht, der Stapelspeicher, die Register, die Ports,
die eingebauten Funktionsmodule/Register/,,Takt.., etc...

Also, hier bist sowohl Software- als auch Hardware_Entwickler.
/// oft ist's mehr Hardware als Software bei unbekannten Strukturen//
Aber das Gegenteil ist auch vorhanden...
Jedoch sollte das ausgewogen sein, weil das Eine kommt niemals! ohne das Andere aus.
Dann ist gut durchdachtes strategisches Arbeiten nötig.

-->> Interessant wird das Ganze in der heutigen Zeit, wenn man
diese alten Prozessoren in eine programmierbare Logik einbaut - zB. FPGA, oder ASIC.
Dann kannst ganz komplexe Prozessoren, für speziellste Anwendungen machen.

Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

» Du kannst die Mnemonic auch selbst schreiben.
»
» Das machst, indem du aus dem Datenblatt die Befehle mit den entsprechenden
» HEX-Codes in eine Tabelle mal herausschreibst.
» Auch die Addressierungsarten musst herausschreiben und dekodieren.
» Das geht alles händisch.
»
» Hier im Beispiel mit dem 6809 von Motorola:
» http://www.lomont.org/Software/Misc/CoCo/Lomont_6809.pdf
»
» Das ist wie eine Landkarte mit Koordinatensystem....
»
» Dann macht !DU den Assembler, indem du' die richtige Syntax schreibst für
» den jeweiligen Befehl.
» Befehl für Befehl, mit' den Register Adressierungen händisch dekodiert
» schreibst.
»
» Hast du alles - das Programm - für deine Anwendung auf zB Papier
» geschrieben.
» Dann kannst daran gehen, die einzelnen HEX-Werte in ein PROM; besser EPROM
» zu brennen.
» Ein EPROM ist hier besser, weil, wenn du Programmfehler haben solltest,
» kannst es wieder löschen und neu beschreiben.
»
» Das Programmiergerät ist auch was "watscheneinfaches".
» Es ist nix anderes, als ein Adressszähler, bei denen du dann bei der
» eingestellten Adresse die Daten
» (zB mit Dip-Schalter umgeschaltet) den HEX-Wert auf den Datenbus anlegt,
» dann machst mit der "Programmier-Taste" -"Zapp!"
» Eine passende Hochspannung von gegebener Schaltzeit "bruzelt"
» daraufhin diesen HEX-Wert in diese Adresse im EPROM-Speicher.
»
» Ein Programm für einen µProzessor, oder µController beginnt normal mit
» einem Sprungbefehl zu den Hardware --> Reset-, bzw. Interrupt_Adressen.
» Auf diesen Adressen liegt normal ein Sprungbefehl - "springe zu
» Reset_Bearbeitungsroutine"; bzw. "Interrupt_Bearbeitungsroutine"....
» Das sind die wichtigsten Eingangsleitungen zum Prozessor/Controller.
» Diese werden auch benötigt, um den Start vom Anlegen der
» Versorgungs-Spannung zum vollen Betrieb geordnet durchführen zu lassen.
»
» So in etwa geht das zu Fuss-Programmieren.
»
» In diesem Fall musst! du den Prozessor und dessen
» angeschlossenen Bausteine -Interfaces genau kennen!
» Musst zB wissen, was die ALU macht, was der Programm-Zähler macht, der
» Stapelspeicher, die Register, die Ports,
» die eingebauten Funktionsmodule/Register/,,Takt.., etc...
»
» Also, hier bist sowohl Software- als auch Hardware_Entwickler.
» /// oft ist's mehr Hardware als Software bei unbekannten Strukturen//
» Aber das Gegenteil ist auch vorhanden...
» Jedoch sollte das ausgewogen sein, weil das Eine kommt niemals! ohne das
» Andere aus.
» Dann ist gut durchdachtes strategisches Arbeiten nötig.
»
» -->> Interessant wird das Ganze in der heutigen Zeit, wenn man
» diese alten Prozessoren in eine programmierbare Logik einbaut - zB. FPGA,
» oder ASIC.
» Dann kannst ganz komplexe Prozessoren, für speziellste Anwendungen machen.
»
» Grüße
» Gerald
» ---

Okay, also ich gucke im Datenblatt nach, welche Befehle der Prozessor versteht und dann könnte ich mir dafür mnemonics ausdenken. Und mein Assembler wandelt einfach die Mnemonics in HexCodes um.

Und der Prozessor kann damit arbeiten, weil vorher die Befehle in das EPROM gebrannt wurden?

Ist das so noch richtig? Oder hab ich da was falsch verstanden?

» Okay, also ich gucke im Datenblatt nach, welche Befehle der Prozessor
» versteht und dann könnte ich mir dafür mnemonics ausdenken. Und mein
» Assembler wandelt einfach die Mnemonics in HexCodes um.

Im richtigen Syntax geschrieben; ja.
Es gibt zudem im Assembler Funktionen, Direktiven zum Einstellen, Makrofunktionen,,,,
die auch mit in das Übersetzen /Compilieren/ einschwingen.

»
» Und der Prozessor kann damit arbeiten, weil vorher die Befehle in das EPROM
» gebrannt wurden?
»
» Ist das so noch richtig? Oder hab ich da was falsch verstanden?

So in etwa,, ganz grob....-> vergleiche mal die oben gepostete Mnemonic mit der eines anderen Prozessors,
Nicht jede ist gleich - Hersteller abhängig;
// dann gibt's auch noch Codes, die offiziell nicht vorhanden sind, bzw. "nicht funktionieren".

--> ZB:
Denke eine Wohnung;
durch die Wohnung, in die jeweiligen Zimmer kommst nur durch geöffnete Türen.
Durch die Wand geht's nicht.
Aber so manchmal fällt ein Ziegel aus der Mauer raus, dann kannst durchschauen, oder gar durch die Wand brechen
und eine neue Tür machen.
Alles im Prozessor sind praktisch mit einer Unmenge verdrahteter Logik-Gates Register, welche mit einer für diese vorgesehene Adresse angesprochen werden.
Auch der ACCU, die ALU, das Statusregister, die Arbeitsregister sind adressiert.
Der Herstellerprozess ist dabei einschränkend.
-> ein RS-FF hat eben auch einen verbotenen Zustand
-> die 2 Ausgänge gleichzeitig auf HIGH//
so auch im Prozessor..
oder manche Hersteller machen solche "Lücken" gewollt;
"Security";; spezielle Zugriffmöglichkeiten von Seiten der Hersteller erhalten.

!! Die Adressierungs-ARTEN machen dann entsprechend das Ansprechen, bzw. verwalten mit denen möglich.

zB. ein 6502 (kann 64kByte mit 16Adr., 65816(kann 16MByte mit 16Adrs.-Leitungen plus 8/Datenbus-Mux/-> SpeicherBank_Adressierung) (diese beiden kenne ich eher aus damaligen Zeiten) hat glaube ich 24(richtig geraten) Adressierungsarten.
--zB absolut, direkt, indirekt, indiziert, relativ,...,,

Prozessor-Blockbild:


Adressierungsarten:


Die Befehls-Matrix - MSD/LSD in der Koordinate ergibt den dort platzierten Befehl:
Darunter ist nochmals die Adressierungsart als Symboldarstellung:



Ein Programm-Beispiel mit diesem Prozessor: geht auch händisch; muss man keinen Makro-Assembler verwenden:



Einfach" ok,,, die Listen in den Datenblättern hernehmen,
Am Besten gleich das Programmier-Manual, welches der Hersteller mitliefert,
und Befehl für Befehl mit allen Modifizierern,
in den Syntax eintragen.
Die Zeilennummern der Befehle sind dann normal die Adressen im EPROM_ ab Start-Adresse sowohl für den Prozessor, als auch u.U. im EPROM.
ZB es muss im EPROM nicht mit Adr-Null beginnen, ist zuallermeist üblich so.
->> Adressierbereich; Prozessor-Eigenschaft bestimmt das u.A.


Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

Es geht eben nix über die alten handassemblierten Programme.

Meine ersten Versuche waren auch noch mit dem Microprofessor auf Z80. Programmlogik ausdenken - Register und Variablen-Plan schreiben und dann die dazu passenden Befehle aus der Mnemonic-Referenz aufschreiben.
Danach die Mnemonic wieder zerlegen und den Steuer-Teil aus der Referenz-Tabelle eintragen. Danach den Datenteil aus dem Programm dazufügen. Das ganze dann auf der HEX-Tastatur in den Programspeicher einhacken und Ablaufen lassen.


Beispiel:

ld HL,1800 = 21 00 18
Der ld-Befehl ist mit 21 kodiert und das Datum wird verkehrt rum in den nachfolgenden 2 Bytes abgelegt.

oder sub a,b => könnte so aussehen:

sub (register) = 101r rmmm mit rr = 00 A, 01 B ....
und mmm = 000 A, 001 B, ... 110 (HL) folgt:
1010 0001 = 0xA1