Hallo!
Das ist gar nicht so einfach zu beantworten!
Zunächst einmal: Der Prozessor hat keine Ahnung von Assembler-Befehlen und kennt sie auch nicht. Das einzige, was der Prozesor kennt, sind Maschineninstruktionen in Form von Zahlenwerten im Speicher.
In den Anfängen der Computerei mußten diese Zahlenwerte von Hand eingetragen werden. Schnell entwickelte man eine 'merkbare' Darstellung dieser Zahlen - ADD, XOR etc. lassen sich nun mal leichter merken und lesen als die Zahlen (üblicherweise sedezimal dargestellt).
Erschwerend kommt hinzu, daß ja auch z.B. Sprungadressen mit Zahlen dargestellt werden - bei den anfangs knappen Speichern mußte man genau ausrechnen, wo ein Unterprogramm zu Ende ist. Nebenbei: bei einer Maschine mit 48KB
RAM und 8080-Prozessor gab es ein Schachspiel, das sich - gelinde gesagt - merkwürdig benahm - spielt mit den Figuren des Gegners weiter, man kann den König schlagen etc. Später wollte mal jemand von einem Spezialisten wissen, ob bei einem Disassembler das mehrfache Laden von Code an dieselbe Adresse berücksichtigt werden muß - diesen Schwachfug hatte er in dem Schachprogramm gefunden. Ursache: UP ab einer bestimmten Adresse geschrieben und das vorherliegende wurde dann etwas größer als geplant, deshalb von nächsten überschrieben.
Später kam man dann auf die Idee, die Umwandlung der Wörter in die Zahlen und besonders die Ausrechnung der Adressen vom Rechner erledigen zu lassen - Programm und Sprache nannte man ASSEMBLER. Die Assembler-Sprache ist immer maschinenabhängig, da ja bis auf wenige Ausnahmen alle Anweisungen zu Maschineninstruktionen werden.
Später wurden dann sogenannte Hochsprachen entwickelt it dem Ziel, die Programme auf mehreren Maschinen einsetzen zu können. Der Transfer geschieht natürlich auf Source-Ebene. Zunächst waren das 'problemorientierte Sprachen' - die geringen Hauptspeicher (ein Rechner mit 64KByte galt als Großrechner und kostete Millionen!) zwangen zur Beschränkung.
Für mathematisch-wissenschaftliche Probleme entstanden FORTRAN (Formular Translation) und ALGOL (Algorithmic Language), wärend für kommerzielle Aufgaben COBOL (Commerciel Businessy Oriented Language) entstand. Eine Textverarbeitung in FORTRAN war genauso ein Krampf wie Rechnen in COBOL - die COBOL-Rechnungen waren geschwätziges ASSEMBLER!
Code:
MULTIPLY A BY A GIVING X // A*A ist schneller als Quadrieren
MULTIPLY A BY B GIVING Z
ADD Z TO X
ADD Z TO X //zweimal addieren schneller als mit 2 multiplizieren
MULTIPLY B BY B GIVING Z
ADD Z TO X
war die COBOL-Codierung für
a-quadrat plus 2 a b + b-quadrat - das denjenigen gesagt, die Programmieren in natürlicher Sprache bevorzugen.
COBOL: Programmiersprache für Programmierer mit eigenem Schreibbüro!
(Ob die Kommentare so gingen, weiß ich nicht. Vermutlich standen die in Spalte 73..80 der Lochkarte).
Später traten dann Universalsprachen wie SIMULA67 (für Simulationen 1967 in Norwegen aus ALGOL60 entwickelt, erste objektorientierte Sprache!!) und PASCAL auf.
Zum Teil werden die Sprachen interpretiert (BASIC), d.h. jede Zeile Source wird analysiert und ausgeführt. Andere wie Delphi werden compiliert, d.h. der Source wird analysiert und dann werden die nötigen Maschineninstruktionen notiert zur späteren Ausführung.
Zuletzt ging der Trend zu Maschinen- bzw. Betriebssystem-abhängigen Sprachen - die ganzen Windows-Controls gibt es ja z.B. unter Linux nicht.
Mit NET soll ja jetzt ein auf Compilat-Transfer aufsetzendes plattformübergreifendes System entstehen. Der Compiler erzeugt nicht Maschineninstruktionen, sondern einen Zwischencode, der dann 'live' in die Instruktionen der Zielmaschine compiliert wird. Vorteil gegenüber Hochsprachen-Interpretern: es ist zur Laufzeit keine Syntaxprüfung nötig, da diese beim Erzeugen des Zwischencodes durchgeführt wurde.
Die Verarbeitung der Maschineninstruktionen im Prozessor ist auch nicht so ganz einfach. Der Prozessor ist nämlich selber ein kleiner Computer! Er nimmt die Instruktionen aus dem Hauptspeicher, decodiert sie und startet die Ausführung. Heutzutage ist es üblich, mehrere Befehle in einer Pipeline zu bearbeiten: während der 1. Befehl seine Ergebnisse speichert, wird der 2. ausgeführt, der 3. decodiert und der 4. geladen. War der 1. Befehl ein Sprung, kann der Rest der Pipeline gelöscht werden - pech. Das geht sogar so weit heutzutage, daß die Prozessoren bei bedingten Sprüngen
beide Zweige (Sprung und nicht-Sprung) vorab bearbeiten und das 'falsche' Ergebnis verwerfen.
Man kann natürlich hardwaremäßig kleinere Rechner mit festverdrahteter Logik darstellen und aufbauen. Das wird aber schnell unübersichtlich - speziell wenn das Ganze mehr als 1 Bit parallel bearbeiten soll.
Frag' doch mal bei INTeL nach - vielleicht rücken die ja Schaltpläne für den 8080 raus
Gruß
Dietmar Brüggendiek