Programmiermodell - Moderne Prozessorarchitekturen: Prinzipien und ihre Realisierungen - page 46

In Tabelle 1.8 sind die Assemblerschreibweisen einiger unterschiedlicher Prozesso-
ren angegeben. Die aufgeführten Befehle unterscheiden sich zum Teil erheblich in
ihren Schreibweisen. So wird die Registerzuweisung in den meist als Transportbe-
fehl realisiert, und zwar hier mit den Mnemonen move, mov, MOV oder mr (move
register). Dort wo kein separater Transportbefehl zur Verfügung steht, wird die ent-
sprechende Funktionalität durch andere Befehle nachgebildet. Bei der Nemesis-
Architektur geschieht dies z.B. mit Hilfe des Oder-Befehls, ähnlich wie beim
UltraSPARC IIIi, bei dem jedoch ein sog. Pseudobefehl verwendet werden kann, um
eine bessere Lesbarkeit der Programme zu erreichen. Beim Transputer T9000 ist,
wegen seiner 0-Adressarchitektur, der Transportbefehl durch ldl (load local) ver-
wirklicht, einem Befehl, mit dem sich der Inhalt eines Arbeitsregisters auf den Sta-
pel übertragen lässt (die oberste Stapelposition ist im Kommentar als A bezeichnet).
Genau wie die Befehle unterscheiden sich auch die Adressierungsarten in ihren
Schreibweisen. So wird ein unmittelbarer Operand in einigen Fällen ohne Zusatz
(z.B. beim Itanium 2), in anderen durch ein vorangestelltes Doppelkreuz gekenn-
zeichnet (z.B. beim i8051). Eine speicherdirekte Adresse ist z.B. in eckigen (z.B.
beim UltraSPARC IIIi), in runden (z.B. beim ColdFire MFC5206) oder ohne Klam-
mern (z.B. beim i8051) beim PowerPC 970 mit nachgestelltem „(r0)“ zu schreiben.
Des Weiteren unterscheiden sich die Registernamen (r1, R1, %g1, eax, ax, A), die
Art in der das Operandenformat im Befehl codiert ist (z.B. move.l, lduh, word ptr)
und andere Details.
1.3.4 Befehlscodierungen
In einer frühen Phase der Entwicklung eines Prozessors definiert man einen Befehls-
satz zunächst entsprechend der gestellten Anforderungen. Dabei wird u.a. entschie-
den, wie viele Adressen in den Befehlen enthalten sein sollen, ob der Prozessor als
Lade-Speichere - oder eine Speicher-Speicher-Architektur realisiert werden soll usw.
Einige im Befehlssatz enthaltene Details, wie z.B. die Anzahl der direkt zugreifba-
ren Register oder die Breite der in den Befehlen codierten unmittelbaren Operanden,
bleiben hierbei zunächst noch unberücksichtigt. Sie werden erst definiert, wenn die
Codierung der Befehle festgelegt wird, um sich nicht der Freiheit zu berauben, Ope-
rationscodes und Adressen in den Befehlen flexibel zu gestalten.
Der in dieser Weise festgelegte Befehlsatz und die Befehlscodierung sind zunächst
nur vorläufig. Erst durch Simulation lässt sich herausfinden, ob die verfügbaren
Befehle tatsächlich den gestellten Anforderungen genügen. Selbst nach umfang-
reichsten Simulationen wird der Befehlssatz und die Befehlscodierung jedoch oft im
Nachhinein noch modifiziert, und zwar, wenn sich z.B. bei der Umsetzung in Hard-
ware herausstellt, dass bestimmte Merkmale sehr kompliziert zu realisieren sind
oder wenn sich bei der normalerweise parallel zur Hardware- laufenden Software-
Entwicklung herausstellt, dass durch geringe Modifikation der Semantik einiger
Befehle das Laufzeitverhalten der auszuführenden Applikationen signifikant ver-
bessert werden kann. In jedem Fall gilt: Je mehr Erfahrungen in den ersten Entwurf
eines Befehlssatzes einfließen, desto geringer sind die Modifikationen, die zu späte-
ren Zeitpunkten noch erforderlich sind.