Diskussion:Adressierung (Rechnerarchitektur)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Adressierung (Rechnerarchitektur)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

ab 2004

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 1500 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 21 Tage zurückliegt. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Artikeltexte ergänzen / korrigieren

Allgemein

Hallo, schön dass sich jemand diesem Thema annimmt. Ich glaube nur, dass nicht so einfach wird hier eine allgemein gültige OMA-taugliche Einleitung zu formulieren. Bevor ich mich inhaltlich äußere muss ich aber noch etwas Literatur durchsehen. Ich denke es wäre günstig auf den QS-Seiten der Elektrotechnik und Informatik weitere Autoren zu diesem Thema zu befragen. -- Cepheiden (Diskussion) 16:56, 4. Apr. 2013 (CEST)

QS wäre ja schon ein letzter Schritt. Mein Hoffnung hier in Wikipedia ist immer, dass die Artikel bei mehreren Autoren auf Beobachtung stehen - und besonders wenn darum gebeten wird, Leute einfach ihren Senf dazugeben. Ist aber leider selten so. Könntest du QS- oder andere Themenleute anbaggern?

Die neue Einleitung ist ja doch sicher ein Fortschritt, besser wäre natürlich eine belegte Definition. Ob die dann die OMA versteht, wäre etwas anderes. Zu 'Unterschiede' könnte man zunächst einfach diese (unstrittige) Aussage 'Es gibt Unterschiede' einstellen und bei Bedarf konkrete Beispiele ergänzen. Schau'n wir mal. Gruß von --VÖRBY (Diskussion) 17:16, 4. Apr. 2013 (CEST)

Einleitung

Hallo, die Einleitung lautet derzeit wie folgt:

Die Adressierung (auch Adressierungsart oder -modus) beschreibt den vom Programm vorgegebenen Weg (welches Programm? Welcher Weg?), wie ein Prozessor die Operanden für eine Rechenoperation (für alle Operationen) im Speicher lokalisiert (unklar) und den Speicherort für das Ergebnis angibt (was heißt das? unpräzise!). Die Zuführung der Adressen zum Speicher (es ist umgekehrt) erfolgt dabei über den Adressbus, während die Operanden aus den adressierten Speicherplätzen über den Datenbus dem Rechenwerk zugeführt werden. Je „lückenloser“ die Operanden im Speicher abgelegt sind, desto schneller kann der Datenzugriff erfolgen. Bei idealer Speicherausrichtung erfolgt der Zugriff besonders schnell, je nach Prozessorarchitektur beispielsweise innerhalb eines Prozessortaktes.

Die m.E. problematischen Stellen habe ich darin in kursiv (mit Erläuterung/Begründung in 'small') markiert und würde den Absatz wie folgt ändern und ergänzen, dies aber zunächst hier kurz zur Diskussion stellen:

„Adressierung“ ist in der Programmierung die Bezeichnung für das Festlegen, auf welche Operanden (z. B. Datenfelder) sich ein Computerbefehl bezieht. Der Ausdruck wird hauptsächlich im Zusammenhang mit Maschinenbefehlen benutzt, wobei die Operanden auf unterschiedliche Art und Weise („Adressierungsart“ oder „Adressierungsmodus“, festgelegt in der Befehlssatzarchitektur des Prozessors) adressiert werden können, zum Beispiel durch direkte Angabe im Befehl oder durch einen Verweis auf eine Speicheradresse. 

Bestimmend für die (durch den Prozessor bei der Ausführung des Befehls) anzuwendende Adressierungsart sind der Operationscode und die im Maschinenbefehl nur in codierter Form enthaltenen Angaben über die Operanden. Diese Maschinenbefehle werden bei Nutzung höherer Programmiersprachen von Compilern erzeugt, weitgehend ohne direkten Einfluss des Programmierers auf die Menge und die Art der Befehle und die anzuwendenden Adressierungsarten. Bei Verwendung von Assemblersprachen hingegen kann oder muss der Programmierer die zu erzeugenden Maschinenbefehle (und damit die Adressierungsart) in höherem Maß selbst bestimmen.

Bezieht sich ein Befehl auf mehrere Operanden (Quell- und/oder Zielfelder), so sind die zur Adressierung erforderlichen Angaben für jeden Operanden getrennt erforderlich/vorhanden. Weitere im Maschinenbefehl enthaltene Parameter (wie Angaben zur Länge von Operanden, Sprungindikatoren aus logischen Befehlen wie gleich oder größer) werden zur Adressierung im engeren Sinn nicht verwendet.    

>>> Die folgenden Texte müssten m.E. nicht in die Einleitung, sondern könnten im Artikel irgendwo ergänzt werden - zumal sich dies wohl nicht nur auf die 'Adressierung', sondern überhaupt auf die Ausführung von Befehlen bezieht.

Zur Ausführung wird der Maschinenbefehl aus dem Hauptspeicher über den Adressbus in den Prozessor übernommen, während im Speicher liegende Daten über den Datenbus ins Rechenwerk transportiert werden. Je „lückenloser“ die Daten im Speicher abgelegt sind, desto schneller kann der Datenzugriff erfolgen. Bei idealer Speicherausrichtung erfolgt der Zugriff besonders schnell, je nach Prozessorarchitektur beispielsweise innerhalb eines Prozessortaktes.

--VÖRBY (Diskussion) 11:32, 2. Apr. 2013 (CEST),
im Einleitungstext ergänzt: --VÖRBY (Diskussion) 12:47, 4. Apr. 2013 (CEST)
angepasst (kürzer): --VÖRBY (Diskussion) 21:00, 4. Apr. 2013 (CEST)
Texte 2 x umgebaut: --VÖRBY (Diskussion) 19:30, 9. Apr. 2013 (CEST)
'Andere Parameter' ergänzt + 'Opcode' neutraler formuliert: --VÖRBY (Diskussion) 10:20, 12. Apr. 2013 (CEST) Compiler/Assembler ergänzt: --VÖRBY (Diskussion) 20:03, 12. Apr. 2013 (CEST) ohne 'Ausführung'; A-Art-Wahl bei ASS: --VÖRBY (Diskussion) 17:05, 13. Apr. 2013 (CEST)

Deine Einleitung ist schon deutlich -hm- korrekter (und gefällt mir diesbezüglich besser als die akuelle), aber meine WP:OmA würde laut "Aua" rufen. Fürs erste reichts vielleicht schon, die Sätze umzubauen zu: kürzer und weniger verschachtelt. Aus den "tatsächlichen Inhalte" würd' ich schlicht "Daten" machen, und den Begriff "Operanden" möglichst erst im 2.Satz einführen. Du erklärt "Adressierung" mit Worten wie "referenziert", "lokalisieren" - also mit Worten, die kaum einfacher sind. Meine Oma kennt eher Begriffe wie "wo sie gespeichert sind", "verwenden", "zugreifen", "Ort, Speicherstelle".

--arilou (Diskussion) 16:14, 9. Apr. 2013 (CEST)

PS: Gibt's auch "nicht-tatsächliche Inhalte" und was ist das Gegenteil zur "physikalischen Ausführung" eines Befehls? Gibt's auch eine nicht-physikalische?

Danke fürs schnelle Feedback. Kurze Antwort (neben den oben einfließenden Aktualisierungen): Tatswächlich ist das Gegenteil von den codierten Adressangaben; verschachtelt schau ich mir an; "Daten" ist nicht immer korrekt, es geht auch um Sprungbefehle; einfachere Worte, versuche ich. Schau mal in den neuen Entwurf. Danke. --VÖRBY (Diskussion) 17:18, 9. Apr. 2013 (CEST)

Alternativer Vorschlag für die Einleitung:

Die Adressierung (auch Adressierungsart oder -modus) ist das Verfahren, mit dem angegeben wird, wo ein Maschinenbefehl seine benötigten Daten findet/wie sie ihm mitgegeben werden/wohin das Ergebnis gespeichert werden soll. Adressierungsarten sind zum Beispiel, die Daten direkt, relativ, indiziert oder in einem Register anzugeben. Im Maschinenbefehl wird in kodierter Form angegeben, welche dieser Adressierungsarten verwendet wird, wo er also die von ihm benötigten Angaben („Operanden“) findet. (Mitunter sind die Daten selbst Adressen, z. B. bei Sprungbefehlen.) Sind für alle verschiedenen Befehlscodes alle Adressierungsarten möglich, so nennt man den Befehlssatz „orthogonal“. Bezieht sich ein Befehl auf mehrere Operanden, so muss die Adressierung für jeden Operand angegeben werden.

--arilou (Diskussion) 10:01, 10. Apr. 2013 (CEST)

Lass mich kurz Stellung nehmen:

• 'angegeben' ist unpräzise
• Es geht nicht nur um Daten, sondern zB auch um Sprungadressen.
• Die Einleitung soll nur das Lemma vollständig und richtig beschreiben/definieren. Die Beispiele sind weiter unten ausführlich behandelt und sollten in der Einleitung m.E. nicht erscheinen.
• Die AdrArt wird im M-Befehl nicht 'angegeben'. Sie ist für den OpCode festgelegt, die Befehlsstruktur muss den Festlegungen zur Adressierung entsprechen.
• Der Prozessor findet die Daten, nicht der Maschinenbefehl
• Bei Adressen hast du evtl. etwas verwechselt, die gibt es nicht nur bei Sprungbefehlen.
• Nicht immer alle möglich: Ebenfalls Missverständnis: Es ist IMMER nur eine möglich.

Fazit: Diese Einleitung ist nicht besser als der Entwurf - den ich auf deine Anregung hin umgebaut hatte. Kannst auch du bitte nochmal mitteilen, was darin falsch oder verbesserungsfähig ist. Danke. --VÖRBY (Diskussion) 13:45, 10. Apr. 2013 (CEST)

Leider ist dein Fazit teilweise falsch:

• zu "angegeben" - ok, da kann gerne ein präziserer Begriff hin.
• "nicht nur Daten" - deswegen kommt ja 3 Sätze weiter die Anmerkung, dass die Daten auch selbst eine Adresse sein können. Das Problem ist, dass man eigentlich 5 Dinge gleichzeitig erklären muss, und das alles in den ersten Satz zu packen, gibt wieder eine Einschub-und-Nebensatz-Orgie. Da muss weniger wichtiges eben bis in Satz 4 warten.
• "Einleitung nur Lemma richtig beschreiben...", ja, aber nicht nur richtig, sondern auch verständlich. Nach dem Lesen der verschiedenen Einleitungsvarianten finde ich, es ist doch sehr erhellend, wenn die möglichen Varianten gleich genannt werden. Die Begriffe "absolut", "relativ", "indiziert" und "im Register" bzgl. Operanden-Auffindort biegen die Gedanken besser in die richtige Richtung, als so manch geschwurbelte "Definition".
• "AdrArt [...] nicht 'angegeben' [sondern] für den OpCode festgelegt" ~ hm, ich würde sagen, das ist eine Frage der Sichtweise. Gibt es 8 verschiedene ADD-Befehle für Register 1..8, oder gibt es 1 ADD-Befehl, in dessen Opcode 3 Bit das zu verwendende Register angeben (was dann auch zu 8 OpCodes führt) ? Bei einem orthogonalen Befehlssatz kann der Programmierer die Adressierungsart bei jedem Befehl frei wählen (andere Sprechweise: Er nimmt denjenigen OpCode, der seiner gewünschten AdrArt entspricht). Und wenn ich zu denjenigen Personen, welche die Adressierungsart "angeben", den Prozessor-Entwerfer dazuzähle, ...
• "Prozessor findet Daten, nicht der Befehl" - nö. Ich habe schon gemerkt, dass du (aus irgendwelchen Gründen) unbedingt drin haben willst, dass es ein "Befehl in Ausführung" ist - aber das ist einfach falsch. Auch Befehle, die noch im Ram liegen, viele Zentimeter vom Prozessor entfernt, haben eine für sie festgelegte Adressierungsart ihrer Daten. (Ausnahme: Selbstmodifizierender Code...)
• "Adressen gibt es nicht nur bei Sprungbefehlen" - richtig. Deshalb steht da ja auch ein "z. B." davor.
• "IMMER nur eine möglich" - da hast du jetzt was falsch verstanden. Bei einem orthogonalen Befehlssatz ist für jeden Befehl jede AdrArt für jeden Operanden möglich. (Andere Sprechweise: Für jede Funktionalität und jede gewünschte AdrArt findet sich ein OpCode.) Manche Befehlssätze sind aber nicht orthogonal - dann ist die Wahlfreiheit eingeschränkt.

"Was [in deinem Einleitungs-Entwurf] falsch oder verbesserungsfähig ist": Ok:

1) "der nächste durch den Prozessor auszuführende Maschinenbefehl" - die Adressierungsart ist auch für die Befehle festgelegt, die noch auf der Festplatte oder im Ram schlummern, gänzlich unabhängig von aktueller Ausführung.

2) "Grundlage dafür sind die im Maschinenbefehl nur in codierter Form enthaltenen Angaben (Operanden), die für verschiedene Befehlscodes eine unterschiedliche Struktur aufweisen können." Ähm, autsch. Der Satz ist ~lass' mich's milde ausdrücken~ nicht leicht verständlich. Den Ansatz, die Operanden als "im Maschinenbefehl enthalten" anzunehmen, ist eher hinderlich für die weitere Erklärung - es erklärt sich imo leichter, wenn man unterteilt in "eigentlicher Befehl", "Adressierungsart-Angabe" und "Daten/Offsets/Registernummer", also z.B.

• Befehl="ADDIERE", Operand1:Quelle, Operand2:Quelle, Operand3:Ziel
• Adressierungsart= Operand1:absolute_Adresse, Operand2:Register, Operand3:absolute_Adresse
• Operand1= 22 (Daten also aus Adresse 22 lesen)
• Operand2= 3 (Daten also aus Register3 lesen)
• Operand3= 27 (Ergebnis also nach Adresse 27 schreiben)

Nun, die nicht kritisierten Teile deiner Einleitung findest du fast wortgleich in meiner wieder (oh Wunder, ich klaue gut *g*).

Vielleicht findet sich eine von uns beiden vertretbare Zwischen-Variante?

--arilou (Diskussion) 14:39, 10. Apr. 2013 (CEST)

PS: Ich war mal so frei, <code> um die Entwurfe zu setzen, damit sie sich deutlicher abheben.

---

Hallo und danke für die intensive Beschäftigung mit dem Thema. Habe soeben festgestellt, dass 'Adressierung' und 'Adressierungsart' eigentlich zwei verschiedene Dinge sind, die Art ist nämlich nur eine Variante für die Adressierung. Insofern kann man das gar nicht sauber mit einer Definition belegen. Ich habs in meinem neuen Entwurf auch getrennt.

Habe auch nochmal Stellungnahmen:

• "nicht nur Daten": Die Definition sollte klar sein, unabhängig von später erscheinenden Aussagen.
• Es muss uns doch möglich sein, eine Definition für 'Adressierung' zu finden, ohne die Beispiele, dazu noch so viele, benutzen zu müssen - sie bringen an dieser Stelle eh nix, weil sie nicht erläutert werden können.
• AA je OpCode festgelegt: Wenn ein orthogonaler Befehl(ssatz) vorliegt, dann gibt es (wie auch du feststelltest) dort auch unterschiedliche Befehlscodes (inkl. RegNr). Wie sollte denn der Prozessor sonst 'wissen', was der Programmier gemeint hat? Trotzdem gibt der Befehl die AA "nicht an", sondern die AA wird aus ihm abgeleitet; Wortspielerei, aber sonst unkorrekt.
• Prozessor oder Befehl: Der Artikel heißt 'Adressierung'. Das ist einerseits ein abstrakter Begriff, mit dem ~ das 'Bestimmen der Adresse' gemeint ist. Dieses Bestimmen ist in einer 'Funktion' (des Prozessors) implementiert, die das für genau einen Befehl tut. 'Nächst auszuführend' habe ich mal rausgenommen, das stört vielleicht tatsächlich. Aber dieses 'für jeweils genau einen Befehl' halte ich für das Verständnis dieses Begriffs schon für wichtig.
• Adressen/Sprungbefehle: Das ist aber ein verwirrendes 'ZB'
• ortogonal hatten wir schon: Immer ist aus dem (ggf. erweiterten) OPCode genau 1 Adr-Art ableitbar.

Ok, weiter im Text *g*:

Wenn ich deine obige, überarbeitete Einleitung lesen, komm' ich so langsam dahinter, warum wir so aneinander vorbeireden.

• Du fokusierst sehr auf die tatsächliche Durchführung der Adressierung - die macht natürlich der Prozessor, für den gerade zu verarbeitenden Befehl. Allerdings entspricht dieser sichtweise der nachfolgende Artikelinhalt eigentlich gar nicht, denn selbiger müsste auf das Adresswerk des Prozessors eingehen u.ä.
• Ich hingegen fokussiere v.a. auf die Adressierungsarten, die es gibt. Selbige beschreibt dann auch der nachfolgende Artikel. Um's mal krass zu sagen - du bist im falschen Film. Wir sollten den Artikel aufspalten in (hießiger Artikel:) Adressierungsart und (neuer Artikel:) Adressierung. Im neuen käme dann, wie genau der Prozessor es anstellt, aus Bestandteilen des Opcodes auf seine konkret zu verarbeitenden Daten zu schließen - ein technischer Vorgang. Hießiger Artikel bliebe dann die Theorie-Erklärung "was gibt es für Adressierungsarten, was bedeutet 'orthogonal'" usw.

Part_1 --arilou (Diskussion) 11:42, 11. Apr. 2013 (CEST)

---

• "nicht nur Daten" - um mehrere Zusammenhänge zu erklären, braucht man mehrere Sätze, oder mehrere Nebensätz (oder mehrere Klammer-Einschübe). Ich persönlich empfinde die Variante "mehrere Sätze" als wesentlich leichter lesbar, als Varianten mit vielen Nebensätzen, Einschüben und Klammern. Dabei ergibt sich nunmal, dass (weil ja mehrere Sätze), nicht alles im 1. Satz erklärt wird. Und dann ist es eben notwendig, dass der geneigte Leser die Definition erst mal zu Ende lesen muss, weil eben nunmal nicht alles im 1. Satz steht. Und dass die Definition aus mehreren Sätzen besteht! Und die Aussage "Die Daten können auch selbst eine Adresse sein, zum Beispiel bei Sprungbefehlen", steht dann eben in Satz 4. Aber wenn du's unbedingt anders haben willst, bitte, wir können auch aus den 5-6 Zeilen der Einleitung einen einzigen langen Satz machen, damit auch ja alles im ersten Satz gesagt wird.
• "Beispiele [...] bringen an dieser Stelle eh nix" - tja, genau das sehe ich deutlich anders. Selbst ohne weiteres Eingehen auf diese 4 oder 5 Begriffe, empfinde ich, dass sie das Denken des Lesers -hm- in eine bestimmte Richtung drehen. Das verdeutlicht imo recht anschaulich, worum es bei einer AdrArt eigentlich geht.
• "AA je OpCode festgelegt" - jein, du bist anscheinend sehr darauf fixiert, "Befehl" mit "Opcode" gleichzusetzen. Richtig, für einen Opcode ist die Adressierungsart festgelegt (zumindest bei den Prozessoren, die ich kenne). Wenn man aber den Begriff "Befehl" gleichsetzt mit "bestimmte Funktionalität" (z.B. "Addieren"), dann nachdenkt, welche Adressierungsart man in der aktuellen Situation braucht, dann in der Opcode-Liste nachschaut, was es alles für ADD-Varianten (z.B. mit unterschiedlichen AdrArten) gibt, und dann den geeigneten auswählt ~ das ist eher meine Denkweise. Zu solch einem "Befehl"s-Verständnis gibts in einem orthogonalen Befehlssatz dann z.B. für den Befehl "Addieren" alle AdrArten, somit 4*4*4 verschiedene Opcodes, ja. Und in dieser Vorgehensweise "gibt der Programmierer die AdrArt an", indem er den entsprechenden Opcode auswählt. Später, bei der Ausführung, "leitet der Prozessor die AdrArt aus dem Opcode ab", ja. Aber das ist nicht die "Ursache", sondern nur noch eine "Folge".

In Maschinenbefehlen gibt es kein 'jein', OpCode ist OpCode: Wenn der Programmierer 'ADD' meint und dann ein bestimmtes ADDxx wählt, dann ist das Gewählte der OpCode, das 'zuerst Gemeinte' die ~ logische Operation. Der Programmierer erstellt (mit Ass- oder Compilerhilfe) Programmcode, der Prozessor führt diesen aus. Dies gilt aber immer, nicht nur für die Adressierung: Was programmiert ist, wird (mit allem was dazu gehört, inkl. Adressierung) entsprechend ausgeführt.--VÖRBY (Diskussion) 12:47, 14. Apr. 2013 (CEST)

"Adressierung" ~ vielleicht muss der Artikel aufgeteilt werden; ich kümmere/argumentiere im Moment bzgl. "Adressierungs-Art", also jene Angaben im Opcode, woher/wohin die Daten für einen Befehl kommen/gehen sollen. Andere "Adressierung"s-Varianten blend' ich im Moment aus, ja.

• "Dieses Bestimmen ist in einer 'Funktion' (des Prozessors) implementiert, die das für genau einen Befehl tut." - aber du stimmst schon zu, dass auch Befehle, die noch im Ram liegen, in ihren Opcodes die Adressierungart(en) ihrer Operanden beschrieben haben - ganz egal ob sie überhaupt jemals ausgeführt werden? Die konkrete Durchführung der Adressierung wird natürlich nur für einen Befehl-in-Ausführung durchgeführt, durch den Prozessor, richtig. Das sehe ich aber als deutlich zweitrangig an, gegenüber der Erklärung des allgemeinen Konzepts, dass es verschiedene Adressierungsarten gibt, welche das sind und wie sie funktionieren.
• "verwirrendes ZB" - ein "Beispiel" bedeutet immer, dass es auch andere Möglichkeiten gibt. Was soll daran verwirrend sein? Es wäre wohl möglich, alle (üblichen) Assemblerbefehle anzugeben, die zwingend eine Adresse als Operand besitzen, aber - in der Einleitung?

Part_2 --arilou (Diskussion) 11:42, 11. Apr. 2013 (CEST)

Deine Hinweise zu 'verbesserungsfähig' (danke):
1)nächst auszuführend: Die 'Funktion' bezieht sich jeweils auf einen Befehl, Art ist immer ableitbar. Habe umformuliert,
2) hab ich auch vereinfacht

Mir war schon immer bewusst, dass 'Operand' ein ggf. missverständlicher Begriff sein kann. Hier im Thema geht es aber dazum, alle Quellen und alle Ziele für einen Befehl zu adressieren, unabhängig davon, wieviele Code-Elemente man (abhängig von der jeweiligen Adressierungsart) für diesen jeweiligen 'Bezug' benutzt. Das ist in der Grafik jetzt auch sichtbar (leider wird bei mir nur die alte Version angezeigt, erst beim Klick kommt die neue)

Ich denke, wir sind SOOO weit nicht auseinander. Grüße von --VÖRBY (Diskussion) 19:36, 10. Apr. 2013 (CEST)

Ich denke, wir liegen tatsächlich erheblich auseinander - es hat nur etwas gedauert, bis bei mir der Groschen gefallen ist - und er tut's wohl auch nur Stüfchen um Stüfchen. Daher schlag' ich (siehe oben) auch das Aufteilen in 2 Artikel vor.

Part_3 --arilou (Diskussion) 11:42, 11. Apr. 2013 (CEST)

Noch ein Nachtrag zu dem von dir skizzierten Beispielbefehl ADD, dessen Zweck ich hier nicht ganz erkenne:

Vorweg: Ich kenne einen solchen Befehl nicht, meine 'Prozessoren' addierten immer nur eine Quelle in ein Ziel; einen Ausdruck "Ziel X = A + B" musste der Programmierer oder der Compiler realisieren.

Trotzdem unterstelle ich mal, sowas gibt es. Dann könnte theoretisch (bei 'orthogonal'?) die Adressierung für jeden der drei Operanden anders stattfinden; in deinem Beispiel könnte man also noch eine indirekte (Reg+Offset) und eine Direktwert-Variante ergänzen. Für jeden der Operanden müsste der Befehl also unterschiedliche Parameter(kombinationen) enthalten.

Bei zB 4 möglichen Adr-Arten ergäben sich somit (kombiniert) für den gesamten logischen Befehl 'ADD' 4*4*4 Möglichkeiten (~Befehlscodes). Der Prozessor müsste diese Kombinationen aus dem OPCode ableiten können.

Eine Adressierungsart-Angabe gibt es in einem Befehl ("eigentlicher Befehl?") nicht, sie wird immer aus dem ggf. erweiterten OpCode abgeleitet.

In deinem Beispiel finde ich die eigentliche Addition nicht. Außerdem dürfte es wohl immer so sein, dass ein Reg-Wert im Rechenwerk direkt verwendet und nicht erst "aus Reg3 gelesen" wird.

Das wollte ich noch anmerken, vielleicht konnte ich damit nochmal klarstellen, was ich meine wenn ich sage, die 'Adressierung' findet für jeden 'Bezugspunkt' des Befehls statt. Denn mit 'Operand' könnte man auch die Register- und die Offset-Angabe jeweils getrennt meinen. Grüße von --VÖRBY (Diskussion) 09:37, 11. Apr. 2013 (CEST)

1) Ich kenne auch keinen Prozessor, der einen derart frei angebbare Addieren-Funktionalität bietet. Aber wir zeigen hier ja auch Assembler-Pseudocode, den muss es nicht konkret geben.

2) (weitere Varianten von ADD als Beispiele) ja, warum nicht.

3) "Eine Adressierungsart-Angabe gibt es in einem Befehl nicht" ~ siehe oben, es kommt drauf an, ob man "Befehl=Opcode" annimmt oder "Befehl=Funktionalität".

4) "eigentliche Addition" ~ richtig, würde das Beispiel aber (unnötig) weiter aufblähen.

5) "Reg-Wert im Rechenwerk direkt verwendet" - nö. Bei Prozessor (Hardware) wird zwischen ALU und Registern getrennt. Für die Erklärung, welche Adressierungsarten es gibt, ist eine solche Trennung auch imo vorteilhaft. Wie's in echter Hardware aussieht ~ egal.

6) Hm, die Sprechweise macht mit ebenfalls etwas Unbehagen. "Operand" verwende ich derzeit etwas salopp sowohl für die Adressierungsart-Angaben oder abs/rel/ind. Adresse, also die -hm- aktuellen Parameter für den gerade gelesenen Opcode; andererseits teilweise auch für die eigentlichen Zahlenwerte, mit denen schlussendlich gerechnet werden soll. Da muss ich noch etwas denken und tüfteln, um das sauberer zu trennen ~ Beispiel:

Die Addition benötigt zwei Eingangswerte und liefert einen Ergebniswert: X = A + B

Der Opcode "ADD_Ziel=Register3_Quelle1=Register3_Quelle2=absolutAdresse" hat nur einen Parameter, nämlich eine Adressangabe (C); schludrigerweise nenn' ich diese Adressangabe machmal "Operand", besser wär's wohl, hier von "Parameter" o.ä. zu sprechen.

Der eigentliche "Operand" (B) ist natürlich der Zahlenwert, der erst aus Adresse (C) zu lesen ist.

Einspruch!!! Das wären doch ganz klar drei Operanden/Parameter/Bezugsobjekte: 2 davon mit Register, 1 als Direktadresse 'angegeben' (!). Die 'Adressierung' wendet 2 mal die A-Art 'Reg-direct' (implizit oder explizit) an und einmal die A-Art 'Direktadresse'. Damit kann der Befehl ausgeführt werden - wie und wo auch immer (das müssen wir hier nicht behandeln, da gebe ich dir recht). --VÖRBY (Diskussion) 12:44, 11. Apr. 2013 (CEST)

Sauber Sprechen ist nicht immer einfach *g* --arilou (Diskussion) 11:42, 11. Apr. 2013 (CEST)

Hallo, da hätten wir ja des 'Pudels Kern'. Ich argumentiere aus der Sicht der Lemma-Bezeichnung. Dass dann (weiter unten) verschiedene Arten beschrieben werden, ist m.E. unproblematisch, es ist für viele Themen der Normalfall und bedarf keines zweiten Artikels. Nochmal Antworten:

• Präzision sollten wir hier in der Enzyklopädie schon anstreben, sowohl sprachlich ('Operand' ...) als auch in der Auswahl von Beispielen.
• 'Angabe' bedeutet, es ist etwas angegeben. Das trifft aber für die A-Art nicht zu, weder im Opcode noch im ganzen Befehl. Vielmehr ist der Opcode nur der 'Schlüssel', mit dem das jeweilige Microprogramm 'adressiert' wird - in dem dann die Versarbeitung der A-Art angestoßen wird.
• Voraussetzung für das Verständnis von 'Adressierung' (und auch von Adr-Art) ist, dass die Adressierung für jedes 'Bezugsobjekt' (ja, nicht offiziell, vlt finden wir noch was besseres) getrennt stattfindet. Dass man dabei jeweils 0 bis n 'Parameter' braucht, ist etwas total anderes. Das muss inhaltlich und möglichst auch begrifflich im Artikeltext klar werden. Siehe auch Grafik.
• Auf den Pseudo-ADD-Befehl brauchen wir wohl nicht mehr einzugehen. Inkl. 'Rechenwerk' etc.
• Auszuführen vs. im RAM liegen: Die Funktion A. (auch die A-Art) hat aber nur etwas mit dem "Ausführen" zu tun. Wenn du die Funktionsweise eines Fahrzeuggetriebes beschreibst, sagst du auch, "das Betätigen der Kupplung trennt Motor und Antriebswelle". Sollte das nicht auch gelten, wenn das Auto in der Garage steht?

Schaffen wir es doch noch?--VÖRBY (Diskussion) 12:29, 11. Apr. 2013 (CEST)

Hallo, ich komme auf Einladung VÖRBYs hier dazu und damit etwas spät. Im Prinzip teile ich anscheinend die Sichtweise arilous, was ich an einem Zitat von ihm erläutern will (von eine Ecke weiter oben): "AdrArt [...] nicht 'angegeben' [sondern] für den OpCode festgelegt" ~ hm, ich würde sagen, das ist eine Frage der Sichtweise. Gibt es 8 verschiedene ADD-Befehle für Register 1..8, oder gibt es 1 ADD-Befehl, in dessen Opcode 3 Bit das zu verwendende Register angeben (was dann auch zu 8 OpCodes führt) ? Bei einem orthogonalen Befehlssatz kann der Programmierer die Adressierungsart bei jedem Befehl frei wählen (andere Sprechweise: Er nimmt denjenigen OpCode, der seiner gewünschten AdrArt entspricht). Und wenn ich zu denjenigen Personen, welche die Adressierungsart "angeben", den Prozessor-Entwerfer dazuzähle, ... - Es gibt eben solche und solche Prozessoren. Beim 6502 gibt es tatsächlich verschieden benannte Befehle für Bearbeiten verschiedener Register, wie TXA (Transfer/kopiere X nach A), TAY (Transfer A nach Y) usw., bei anderen Prozessoren (z. B. Z80) gibt es einen einzigen MOV-Befehl mit verschiedenen Registernamen als Operanden. Auf Hardwareebene sind sich jene Proezssoren dann aber wieder viel ähnlicher, weil auch beim 6502 die Register als Bitgruppe in der sonst gleichen Befehlskennung enthalten sind. Sprich, die Assemblerbefehle sind stark unterschiedlich definiert, die Maschinenbefehle eine Ebene tiefer aber sehr viel ähnlicher, auch die Assembler-Mnemonics sind schon eine Abstraktionsstufe, die von den Entwicklern unterschiedlich realisiert werden kann. - Und wie arilou korrekt anführt, gibt es (spätestens bei orthogonaler Adressierung) einen Befehl, aber mit mehreren verschiedenen Opcodes, je nach Adressierungsart, in der man den Befehl gerade verwendet.

Ein Satz im Artikel, den ich für richtiggehend falsch halte, ist Normalerweise muss sich der Programmierer nicht um diese Adressierungsangaben kümmern, da meist der Assembler oder Compiler dies übernimmt. Jeder Programmierer, der in Assembler programmiert, muss sich sehr wohl und ständig um die Adressierungsangabe kümmern. Der Assembler kann ihm das gar nicht abnehmen, sondern stellt ihm vielmehr diese verschiedenen Varianten als Wahl-Optionen zur Verfügung, aus denen der Programmierer dann gezwungenermaßen die jeweils passende auswählen muss. Das kann der Assembler dem Programmierer nicht abnehmen. Diesen Satz also bitte ersatzlos streichen, er ist blanker Unsinn. - Dass das beim Programmieren mit einem Compiler anders aussieht ist klar, bloß das ist eine andere Welt, im Rahmen dieses Artikels hier bewegen wir uns dagegen in der Welt der Maschinenbefehle, Assemblerbefehle (nicht dasselbe, siehe Absatz davor) und Opcodes. --PeterFrankfurt (Diskussion) 02:29, 12. Apr. 2013 (CEST)

Danke für den Senf. Es ging in diesem Aspekt der Disk um die 'Formulierungs-) Frage, ob IM Befehl die Adressierungsart 'ANGEGEBEN' ist. Wie du selbst feststelltest, gehört der Aspekt, wie der Befehl entstanden ist ('Compiler', Wahl des Programmierers) nicht in die "Welt der Maschinenbefehle", also nicht in dieses Lemma hier. Die Fragestellung ist inzwischen durch Umformulierung ("Grundlage ist der Maschinenbefehl") geklärt - was immer gilt, egal ob orthogonal oder sonstwie.

Im Artikeltext muss noch vieles mehr korrigiert werden; die Aussage 'Programmierer muss sich kümmer' ist aber in dieser Form wirklich Fehl am Platz. Tschüss Frankfurt! --VÖRBY (Diskussion) 10:20, 12. Apr. 2013 (CEST)

Äh, wie? Wie gesagt, ich behaupte, mit diesem ganzen Lemma bewegen wir uns definitiv NICHT in der Welt der Compiler, sondern in der von Assemblern und Maschinenbefehlen. Und da muss alles explizit angegeben werden. Ob als Argument eines Befehls oder gleich durch seinen Namen in einer bestimmten Variante, ist unerheblich. Auf jeden Fall muss es auf dieser Ebene ausdrücklich ausgewählt und angegeben werden. --PeterFrankfurt (Diskussion) 17:27, 12. Apr. 2013 (CEST)

Verstehe nicht ganz: JA! Wir bewegen uns NICHT bei Compilern und eigentlich auch nicht bei Assemblern, sondern nur bei MASCHINENBEFEHLEN - egal woher die kommen. Argumente als Namen gibt es da ("auf dieser Ebene") nicht und "ausdrücklich auswählen" auch nicht, das geschieht beim Programmieren. Du hast das aber im Artikel schon entsprechend eingestellt, passt. --VÖRBY (Diskussion) 18:17, 12. Apr. 2013 (CEST)

---

Hallo zusammen, habe i.Z. mit diesen Disk-Beiträgen festgestellt, dass Adressierung nicht nur beim Ausführen, sondern auch beim Erzeugen des Maschinencodes, v.a. bei Assembler, "eine Rolle spielt". Das hatte ich bisher (vielleicht basierend auf den alten Texten) vernachlässigt. War vielleicht auch Ursache von Missverständnissen hier. Habe im Textentwurf aktualisiert. Sorry!!! --VÖRBY (Diskussion) 20:03, 12. Apr. 2013 (CEST)

Ich habe den Entwurfstext nochmal angepasst, die Betonung der 'Ausführung' rausgenommen ('Prozessor' aber dringelassen!) und auch die Bedeutung des (Ass-) Programmierers berücksichtigt. Besser?
P.S.: In der :en.WP heißt der Artikel (lt. Sprachlink) übrigens nicht Adressierung sondern 'Addressing mode'. Ich denke aber, dass man beide Aspekte in einem Artikel gut nebeneinander führen kann.
--VÖRBY (Diskussion) 17:05, 13. Apr. 2013 (CEST)

Na endlich X-) ist bei Dir der Groschen "Die Sicht des Programmierers" ("beim Erzeugen des Maschinencodes") gefallen.

Jetzt wär's nur noch nett, in der Einleitung zwischen diesen beiden Sichtweisen abzugrenzen. Vielleicht sogar explizit zu nennen, dass es beim Assemblerprogrammieren die (eingeschränkte) Wahl der Adressierungsarten gibt (durch Wahl eines entspr. Opcodes), und andererseits der Prozessor bei der Ausführung dann die konkrete Adressierung durchführt. --arilou (Diskussion) 11:23, 15. Apr. 2013 (CEST)

Jetzt mal Nägel mit Köpfen. Ich hab' VÖRBYs Einleitung etwas abgeändert und jetzt erst mal als neue Einleitung in den Artikel übernommen. Ab jetzt also Diskussion wieder über den Artikel direkt. --arilou (Diskussion) 11:46, 15. Apr. 2013 (CEST)

Sind wir ja doch noch zusammengekommen, trotz 'Befehle im RAM', Rolle des Programmierers etc. Das mit den Groschen gilt wohl für beide Seiten.

Die bisherige Beschreibung hatte voll auf Maschinencode abgestellt; es kann aber nicht schaden, am Rande auch das Entstehen dieses Codes zu betrachten - obwohl es eigentlich nicht zum technischen Vorgang der Adressierung gehört. Mein erster Satz war deshalb diesbezüglich bewusst offener gehalten: Operanden eines 'Computerbefehls'. Jetzt sind wir wieder bei 'Maschinenbefehl' - ok.

Hab nochmal etwas umformuliert und hoffe, auch dir passt das noch. Danke fürs Mitarbeiten - hier in der Einleitung. Weiteres wäre ja auch noch vakant. --VÖRBY (Diskussion) 12:59, 15. Apr. 2013 (CEST)

Yup, ist die Einleitung ist ok so.

Kleinigkeit: "[...] führt die entsprechenden Adressrechnungen sowie das Laden der dabei zu verwendenden Daten durch."

Etwas zweideutig: "dabei zu verwenden" - bei der Adressrechnung? Oder bei der anschließenden "eigentlichen" Befehlsausführung?

--arilou (Diskussion) 15:22, 15. Apr. 2013 (CEST)

Teilabschnitt ERLEDIGT: --VÖRBY (Diskussion) 17:00, 15. Apr. 2013 (CEST)

Eigentliche Adressierung

... Fortsetzung vom vorherigen Abschnitt
Habs korrigiert, danke. BTW: Das wäre doch auch ein Ansatz, den du schon mal erwähnt hattest: Der Artikel heißt 'Adressierung', befasst sich aber in der Hauptsache mit der Beschreibung der Adr-Arten. Eine Stufe tiefer findet ja dann die tatsächliche Adressierung in der Befehlsausführung statt. Ich könnte mir vorstellen, diesen Sachverhalt in einem eigenen Hauptabschnitt '~Adressieren beim Ausführen des Befehls' zu erläutern. Dabei müsste nach meinem Verständnis beschrieben sein, WO (in welchem Prozessorteil, Register, Rechenwerk-Element etc) WAS (die Adressen oder die Daten) und ggf. WIE eingestellt wird, so dass der 'Befehlsautomat' nur noch ablaufen muss und dabei seine "Schnittstellen" richtig trifft. Bist du darin firm? Die Sache mit dem Adress- bzw. dem Datenbus (jetzt nicht mehr im Artikel!) würde da wohl auch reinpassen. --VÖRBY (Diskussion) 16:58, 15. Apr. 2013 (CEST)

Unterschiede abhängig vom Befehlssatz

Im Kapitel 'Unterschiedliche Bezeichnungen' ("Fallstricke" würde ich weglassen) müsste noch ergänzt werden, dass in den einzelnen Rechnerarchitekturen nicht alle Adressierungsarten und nicht alle in der selben Art und Weise möglich sind. Dass sie unterschiedlich genannt werden, ist ja schon gesagt. Zum Beispiel gibt es beim 360/390-Zeichensatz keine 'Direktadressierung', alle Adressen werden durch Register + ggf. Offset (mit nur 2 Bytes) dargestellt. Auch gibt es keine Registerangabe 'im OpCode'. Wenn jemand weitere Beispiele beisteuern kann, könnte/sollte man dies ergänzen. Dies ist gerade auch deshalb sinnvoll, weil sogar Entwickler oft nur in einer Architektur denken.--VÖRBY (Diskussion) 16:31, 4. Apr. 2013 (CEST)

Ich habe den Abschnitt neu gegliedert und i.W. Bezeichnungen und Inhalte unterschieden. Es wäre zweckmäßig, dort weitere 'Spezialitäten' aus einzelnen Befehlssätzen zu ergänzen. Aus meiner Sicht: Vorläufig ERLEDIGT. --VÖRBY (Diskussion) 18:46, 15. Apr. 2013 (CEST)

Typische Adressierungsarten ...

Die Texte aus der Aufzählungsliste am Anfang des Abschnitts könnten in die später folgenden Unterabschnitte eingearbeitet werden. Doppelte Beschreibungen mit potenziell unterschiedlichen Texten (auch für die Zukunft) wären so vermeidbar. --VÖRBY (Diskussion) 12:06, 12. Apr. 2013 (CEST)

Habe die Texte vereinigt. ERLEDIGT. --VÖRBY (Diskussion) 09:32, 15. Apr. 2013 (CEST)

Danke Arilou für die QS. --VÖRBY (Diskussion) 17:05, 15. Apr. 2013 (CEST)

Beispielgrafik

Schema für alternative Adressierungsarten von Maschinenbefehlen

Diese Grafik kann der 'OMA' halfen, die Zusammenhänge zu verstehen. Sie zeigt, in welchen Varianten die Operanden des Maschinenbefehls spezifiziert und in die für ihn relevanten Adressen/Daten umgesetzt werden können.--VÖRBY (Diskussion) 11:32, 7. Apr. 2013 (CEST)

Wird bei mir leider nur in der Version 1 angezeigt; aktuelle Grafik bitte Klicken. --VÖRBY (Diskussion) 09:37, 11. Apr. 2013 (CEST)

Jetzt klappt es aber anscheinend. Warum weiß der Himmel. --VÖRBY (Diskussion) 11:07, 11. Apr. 2013 (CEST)

In der Adressierung muss für jeden 'Bezugspunkt' (siehe rote Pfeile!) des (Maschinen-) Befehls die 'Adressierung' hergestellt werden. Manchmal reicht dazu eine Reg-Angabe, manchmal zusätzlich ein Offset usw. Um 'Adressen' gehts also immer. Wenn ein Befehl zwei 'Bezugspunkte' hat (Bsp: 'Add Speicherfeld zu Reg x'), dann ist der eine Bezugspunkt nur das Reg. (und seine Adresse ist die RNr), der andere wird zB durch Reg+Offset definiert (und seine Adresse liegt im HSp). Man darf also die 'Anzahl der Parameter' eines Befehls nicht mit den Adress-definierenden Elementen gleichsetzen. Daraus ergeben sich ja schließlich die unterschiedlichen Adressierungsarten.

In der Grafik wird das Format des Maschinenbefehls nicht gezeigt, nur verbal gesagt, über welche Adr-Elemente die 'Adresse' festgestellt wird. Das kann ich noch ergänzen. Auch zeigt die Grafik (genau wie der Artikeltext) die Adressierung nur eines von evtl. mehreren Zieldatenfeldern.

Jedenfalls Danke vorest fürs Feedback. --VÖRBY (Diskussion) 20:00, 9. Apr. 2013 (CEST), ergänzt: --VÖRBY (Diskussion) 08:16, 10. Apr. 2013 (CEST)

Ich habe die Grafik eingestellt; ERLEDIGT.--VÖRBY (Diskussion) 09:33, 15. Apr. 2013 (CEST)

Redundanz zu Adressrechner (Maschinenbefehl)?

Dort ist etwas Ähnliches beschrieben. Kann das jemand sicherer als ich beurteilen? Mir erscheint das ist irgendwie nicht konsistent: Denn dort ist einerseits von Maschinenbefehl die Rede, andererseits sind zu jeder Variante mehrere Assemblerbefehle als Beispiel aufgeführt. --VÖRBY (Diskussion) 11:07, 11. Apr. 2013 (CEST)

Idee: Die dort auch grafisch erläuterten Details könnten einen anderen Aspekt von 'Adressierung' beleuchten: Nämlich wie das Ansprechen der durch die A-Art festgelegten Operanden bei der pyhsikalischen Befehlsausführung tatsächlich geschieht. Durch eine Übernahme HIER ins Lemma würde der Artikelinhalt auch der Lemmabezeichnung entsprechen und sich nicht nur (i.W.) auf die A-Arten beschränken. Wenn man das Ganze dann 'Adressierung (Maschinenbefehl)' nennen würde, wäre alles korrekt und in einem Artikel beschrieben. (kurze) Meinungen? --VÖRBY (Diskussion) 09:07, 12. Apr. 2013 (CEST)

Beispiele

Die Beispiele sind vmtl. von einem C64-Programmierer und nicht ganz konsequent. Der ADD-Befehl erhält 3 Parameter, aber einmal sind's Adressen, ein anderes mal Offsets, trotz gleicher Schreibweise. Verwirrend das ist... --arilou (Diskussion) 16:45, 9. Apr. 2013 (CEST)

Die Beispiele sind aus den Texten abgeleitet - und so kenne ich sie auch als Host-Programmierer.

Kommentar von VÖRBY als Antwort auf die missverstandene C64-Frage (wurde auf eine Antwort zur Beispielgrafik interpretiert)

Deine Kenntnisse in Ehren, aber hier geht's nicht um Programmierung mit einem bestimmten Assembler-Dialekt, sondern um einen Enzyklopädie-Artikel. Da ist eher Pseudocode/Pseudo-Assembler gefragt. Ich überarbeite mal den gesamten Beispiele-Abschnitt. --arilou (Diskussion) 10:42, 10. Apr. 2013 (CEST)

Hier die Disk (zumindest meine Antwort darauf) bezog sich auf die Beispielgrafik. Ich habe deshalb deine Unter-Überschrift nochmal entfernt.

Die o.a. Abschnitte und die Grafik hat überhaupt nichts mit Ass-Dialekten zu tun, sondern schlicht und einfach mit 'Maschinenbefehlen' - zu denen (hier in der Enzyklopädie) beschrieben werden soll, wie die in ihnen enthaltenen Adress-Operanden vom Prozessor angesprochen werden können.

Sorry wenn es aus deiner Sicht um was anderes geht als die Beispielgrafik. Dann solltest du aber klarer sagen, welche Beispiele zu meinst - und mein Kommentar gehört dann nicht hierhin.--VÖRBY (Diskussion) 13:27, 10. Apr. 2013 (CEST)

Habe jetzt gesehen, dass du im Abschnitt 'Beispiele' Änderungen größeren Umfangs eingearbeitet hast, deine Fragestellung sich also NICHT auf die Beispielgrafik bezogen hatte. Vielleicht wären zunächst auch hier Diskussionen von Vorteil gewesen :-( Abschnitt wieder zum ==Hauptabschnitt== gemacht; sorry. --VÖRBY (Diskussion) 14:03, 10. Apr. 2013 (CEST)

Sorry dafür, dass es missverständlich war (sodass du's auf die Grafik bezogen hast).

Nach dem Gemurks bei Compiler bin ich mittlerweile stärker ausgerichtet auf "Arbeit direkt am Artikel" anstatt endloser Diskussion. Dafür braucht man allerdings ein recht dickes Fell, da direkte Artikel-Änderungen (da sie ja ~hm~ ernsthafter sind) heftiger angegriffen und diskutiert werden. Dafür tut sich auch mehr X-)

--arilou (Diskussion) 14:55, 10. Apr. 2013 (CEST)