Diskussion:Opcode

message: Das Ergebnis ist bisher aber mager, Es fehlt eine ganze Menge zur geschichtlichen Entwicklung. Da müßte die weitere Entwicklung über Freiburger Code zu Tokencodes usw. dazu kommen. --SonniWP2 23:00, 30. Jul. 2007 (CEST)

message: Dieser Artikel kommt mir persönlich vor, wie eine Maschinen-Übersetzung aus dem Japanischen. Unbedingt verbessern! -- 217.93.67.136 21:55, 12. Jul. 2009 (CEST)
replies: text: Stimmt nicht. Ist flüssig zu lesen. --Musbay 22:16, 15. Jul. 2009 (CEST)
replies: text: Argument "Maschinen-Übersetzung" kann ich ebenfalls nicht nachvollziehen, Baustein daher wieder entfernt. Gruß --Howwi 10:04, 2. Aug. 2009 (CEST)

text: Die dritte Lochungsart (der Punkt) ist die sog. "Transportlochung", die immer asymmetrisch zur Mittellinie des Streifens gestanzt wird, und zwar mit sehr viel kleinerem Lochdurchmesser. Diese Lochung steht für kein Datenbit, sondern gibt die Position von auf gleicher Höhe liegender Datenlöcher an. Beim Binärwert Null wird ja gar kein Loch gestanzt, und am Transportloch sieht der Leser dann, dass er an dieser Stelle diesen Nullwert so nehmen soll. Siehe auch Bilder bei Lochstreifen und Baudot-Code. - Und wie Zuse das Z codiert hat, weiß ich nicht. Zu seiner Zeit gab es ja schon Fernschreiber mit ihrem 5-Kanal-Baudot-Code, aber seine Maschine hatte ja 8 "Kanäle" (Lochpositionen, bei Baudot wird der Unterschied zwischen "Kanal" und "Bit" erklärt). --PeterFrankfurt 23:41, 20. Dez. 2009 (CET)
replies: text: 'Z' wird nicht codiert, 'zzzzzz' bedeutet, dass dort mit 6 Bit (6 Mal Loch 'o' oder nicht Loch '-') die 64 Wortspeicher der Z3 adressiert, also eingestanzt werden. Das ist nur ein Platzhalter in der Darstellung.Siehe Spalte Beschreibung: "Lesen der Speicherzelle z (erst R1, danach immer R2) " und "Schreiben von R1 in Speicherzelle z" --2.247.244.147 19:30, 10. Jan. 2018 (CET)

text: Nee, ich glaube nicht, dass das allgemein für alle Prozessoren gilt. Irgendwelche Bitgruppen innerhalb des Befehlsbytes/-worts haben zwar oft eine direkte Bedeutung, z. B. eine Registernummer in binär, dieselben Bits haben aber bei anderen Befehlsklassen gerne dann eine vollkommen andere Bedeutung. Da kann man wohl nichts verallgemeinern. --PeterFrankfurt 02:41, 18. Nov. 2010 (CET)
replies: text: Nein, man kann wirklich nichts verallgemeinern. Wenn unten die Decodierung angesprochen ist: Bei den frühen Prozessoren mit wenig Befehlen kann man einfach die 8 Bits Befehlscode nehmen, sie in einen Demultiplexer mit 256 Ausgängen stecken und die Ergebnisse einfach so verdrahten (oder viele eben wegen nicht belegter Codes gar nicht). Nur an wenigen Stellen kann man da per einer gewissen Systematik ein paar Bits zu gesonderter Decodierung herausgreifen. Und wie geht das in der Wissenschaft: ein Gegenbeispiel genügt, um ein angenommenes System zu widerlegen. Sieh Dir das konkret beim 6502 an, das riecht eben nach Handverdrahtung der Decodierung. Da gibt es in einem Teil des Befehlssatzes Bits zur Codierung der Adressierungsart, da ist bei den Branches das eine Nibble konstant und das andere unterscheidet die Branchbedingungen, aber das ist dann auch schon alles an Systematik. Da ist einfach kein "Prinzip", das überall gleich sein könnte. --PeterFrankfurt 02:23, 19. Nov. 2010 (CET)
replies: text: Was Du als "Systematik" erkennst, ist das Prinzip. Wo ist also Dein Problem mit dieser Tatsache: das Prinzip des Opcodes ist die parametrische Beschaltung der Funktionseinheiten eines Prozessors. Ob nun direkt beschaltet oder durch Demux, Selektoren oder was auch immer bearbeitet, ändert nichts daran. Mir leuchtet nicht ein, warum Du das nicht wahrhaben willst. Zwar "riecht" gerade beim 6502 absolut nichts nach Handverdrahtung, die Steuerung übernimmt hier ein Logik-Array, aber was Du sagen willst, ist doch prinzipiell richtig. Konstruktiv gesehen ist der 6502 für die Veranschaulichung aber viel zu komplex, da wäre eher die Größenordnung einer 2-Bit Maschine geeignet (und übrigens als Verallgemeinerung gültig). Und wie ist das mit der Wissenschaft? Es ist gängige Praxis, eine These oder einen Beweis durch ein Gegenbeispiel zu entkräften. Dass das auch auf Verallgemeinerungen zutrifft, ist mir allerdings neu, denn es ist das Wesen der Verallgemeinerung, dass sich hier um der Einfachheit willen Widersprüche im Speziellen ergeben können. Da hast Du Falsifikation nicht so recht verstanden. Geschenkt. --Mihalog 09:52, 19. Nov. 2010 (CET)
replies: text: "Systematik" kann ich proklamieren, wenn ich sagen kann, "Bits 2 bis 4 geben immer Registernummern an, Bits 5 bis 7 immer die Adressierungsart". Das wird in der Praxis aber eben nicht so durchgehalten, also halte ich die Zuschreibung so einer Systematik einfach für falsch. --PeterFrankfurt 02:00, 20. Nov. 2010 (CET)
replies: text: Ich rede nicht von Systematik, sondern von Prinzipbeschreibung. Eine klassische Systematik, wie Du sie vorschlägst, halte ich auch für falsch, aber damit hast Du ja auch angefangen. Das Prinzip lässt sich an einem einfachen Beispiel darstellen und gibt dem Leser die Möglichkeit, auf komplexere Systeme zu schließen. Eine einfache Frage: warum lautet der 6502 Opcode für die Zeropage-Addition gerade $65? Wenn Du das richtig beantworten kannst, verstehst Du, was das Prinzip ist. --Mihalog 15:56, 21. Nov. 2010 (CET)

text: Das würde eine Redundanz bedeuten. Das sehe ich aber nicht so: Jener Artikel beschreibt die hardwaremäßige Implementierung dessen, was eher als Konzept und als Softwareaspekt in diesem Artikel hier beschrieben wird. Das ist in meinen Augen schon eigenständig genug. --PeterFrankfurt 02:23, 19. Nov. 2010 (CET)
replies: text: 1. Definiere bitte "Softwareaspekt". 2. Was nutzt der Opcode ohne Befehlsdekoder und umgekehrt? Wo ist die Eigenständigkeit beider Konzepte? --Mihalog 09:52, 19. Nov. 2010 (CET)
replies: text: Es geht nicht darum, wer wem nutzt, sondern wer was macht. Und der eine ist die Hardware (der Befehlsdecoder) und der andere die Software (der Befehlssatz). Letzterer dient als Abstrahierung für den menschlichen Programmierer und Programmleser. Sieh Dir als Beispiel die Befehlssätze von 8080 und Z80 (bei letzterem nur den 8080-identischen Teil) an: Sie machen dasselbe, die Hardware dafür ist die selbe, aber die Befehlssätze sind extrem unterschiedlich, wo der 8080 Befehle wie LDA, STA und MOV kennt, spricht der Z80 übergreifend von LD. Das ist also von der Hardwareimplementierung komplett losgelöst und separat zu betrachten. --PeterFrankfurt 02:00, 20. Nov. 2010 (CET)
replies: text: Wovon Du sprichst nennt man Mnemonic, das ist eine menschenlesbare Form des Opcodes. Ich schlage vor, dass Du Dich vielleicht lieber dort einbringst. Der Opcode bleibt nach wie vor die programmierbare Beschaltungsvorgabe und ist damit genau die Schnittstelle zwischen Hardware und Software. Welche Mnemonics sich ein Prozessor-Konstrukteur für die Assemblersprache seines Prozessors ausdenkt hat exakt nichts mit der Technik zu tun. --Mihalog 15:56, 21. Nov. 2010 (CET)
replies: text: Unter "Befehlssatz" verstehe ich aber das, was in einem Handbuch als zur Verfügung stehende Befehle aufgelistet ist. Wie der Hersteller die Befehle in zusammengehörigen Gruppen sortiert, hat auch was mit der technischen Realisierung zu tun und ist nicht nur eine textliche Geschmackswahl. --PeterFrankfurt 00:13, 22. Nov. 2010 (CET)
replies: text: Es geht ja auch um den technischen "Opcode" und nicht den Assembler-"Befehlssatz". Du bringst da zwei Sachen durcheinander, die zwar zusammenhängen, aber konzeptionell zu trennen sind. Der Mnemonic, also der "Befehl" in Deinem Verständnis ist sogar ausschließlich eine Geschmackswahl, der Opcode ist als Beschaltungsvorgabe technisch bedingt. Ich neige ja nicht zu Buchempfehlungen zur Diskussionsverkürzung, aber bitte besorge Dir mal "Hennessy & Patterson: Computer Architecture", da stehen echt eine Menge wissenswerter Sachen zum Thema drin. Ist ja nicht so, dass ich selbst Dich belehren wollte. --Mihalog 01:06, 22. Nov. 2010 (CET)
replies: text: Seufz, denk Dir, ich weiß, was ein Mnemonic ist. Aber davon sprach ich ja auch gar nicht. Ich sprach von einer (logischen) Gruppierung von Befehlsgruppen/-familien (also was sich in bestimmten gemeinsamen Bitmustern niederschlagen könnte/müsste), die primär in der Hardware realisiert wird, sich dann aber auch in der textlichen Beschreibung wiederfindet. Wenn nun wie bei Z80 vs. 8080 völlig verschiedene Mnemonics (und vor allem deren Gruppierungen bei LD vs. LDA/STA/MOV) vorkommen, legt das für mich nahe, dass auch die interne Hardwarerealisierung unterschiedlich sein könnte. --PeterFrankfurt 01:33, 22. Nov. 2010 (CET)
replies: text: Schluchz. Ich glaube Dir. Aber da Deine Antwort im vorwiegenden Konjunktiv verfasst ist, lass es uns dabei belassen: dieser Artikel behandelt den Opcode, ein anderer den Mnemonic und ein dritter Assembler (auch eine recht prinzipielle Bezeichnung für lesbare Maschinensprachen; wie die sich da wohl einig werden...). Da möglicherweise CPU- und Hardware-Design im Allgemeinen nicht Dein erster Broterwerb sind, schlage ich direkt für heute abend als geeignete Lektüre vor: http://www.intel.com/about/companyinfo/museum/exhibits/4004/docs.htm . Finde ich zumindest großartig. (Oder alle Werke von Rodnay Zaks). --Mihalog 02:05, 22. Nov. 2010 (CET)
replies: text: Ja, schöner Link. Und? Willst Du andeuten, dass alle Prozessoren genau so wie der 4004 strukturiert sind? Beachte bei ihm auch das Detail, dass bei manchen Sprungbefehlen schon die zweite Hexziffer Teil der Sprungzieladresse ist. Also auch hier gibt es kein einheitliches Prinzip, wie sich das Codebitmuster auf die Funktion übersetzt. Mein Reden. Und nein, ich habe noch keinen Prozessor konstruiert, nach intensiver Benutzung von 8085 und 6502 (zu Anfang per Handassemblierung) hatte ich aber diverse Gedanken, wie ich es gerne hätte noch ein bisschen besser machen wollen... --PeterFrankfurt 01:55, 23. Nov. 2010 (CET)
replies: text: Nein das will ich nicht, das ist doch auch Unsinn. Das war dazu gedacht, Dir ein Beispiel für eine sehr einfache Konstruktion zu geben. Ich muss wohl mal klarstellen, dass wir von unterschiedlichen Richtungen auf den Opcode schauen. Von oben, von der Programmierung aus ein Prinzip, oder genauer: eine Kategorie zu suchen hat natürlich überhaupt keinen Zweck. Da bin ich Deiner Meinung, das meine ich aber gar nicht. Die Frage ist nach wie vor, wie ein Opcode (bottom up) entsteht und lass es mich nochmal versuchen: die Opcodes ergeben sich aus der Prozessorkonstruktion. Es geht nicht darum, WO welche Bits im Opcode welche Funktion steuern, sondern WARUM sie da sind. Mein Beispiel der ALU gilt immernoch, obwohl das sehr stark vereinfacht ist. (1) Konstruiere eine einfache ALU mit meinetwegen Volladdierer und drei booleschen Operationen. (2) Wieviele Steuerleitungen brauchst Du? Genau: zwei. (3) Wie lauten die Opcodes? Auch richtig: kommt drauf an, in welcher Reihenfolge der Selektor am hinteren Ende der ALU die Funktionseinheiten ausführt, aber vermutlich erstmal 00,01,10,11 (0,1,2 und 3). (4) Wie weiß die ALU, was sie verarbeiten soll? Du gibst ihr einen Tipp: hast Du z.B. vier Register, dann codierst Du natürlich 00-11 (0-3) und gibst zwei Register für die Operation an. Durch einen Selektor werden die Registerinhalte aus dem entsprechenden Latch auf die ALU geschaltet. Als Opcode ergibt sich mithin für eine Operation 2 mit Registern 0 und 3 z.B. "100011", also "35" oder "$23" und vielleicht "ADD 0,3" als Mnemonic. (5) Um jetzt noch eine Variante zu bringen, definierst Du nicht einzelne Register, sondern Paare und codierst (00,01,10,11) für (0,1),(0,2),(0,3),(1,0). Das vermindert zwar die Möglichkeiten, verkürzt aber den Opcode (Designentscheidung). Die Registerauswahl wird dann nicht direkt auf einen Selektor geschaltet, sondern muss vorher de-multiplext werden. Die gleiche Operation von eben hätte dann den Opcode "1010" und hieße immernoch "ADD 0,3". Dieses Vorgehen ist PRINZIPIELL immer so. Und damit zurück zur Eingangsfrage dieses Abschnittes: ist der Opcode als Konzept eigenständig? Ich finde nicht. --Mihalog 13:58, 23. Nov. 2010 (CET)
replies: text:  Und siehst Du, genau von diesen Designentscheidungen, wie Du sie zwischendrin erwähnst, rede ich. Da gibt es auf Hardwareebene mehrere verschiedene Wege der Implementierung und *unabhängig* davon gibt es auf der Abstraktionsebene hin zu Mnemonics mehrere Wege, die Bitmuster zu offiziellen Befehlen zusammenzudefinieren. Im Opcode gibt es zusätzlich noch die Designentscheidungen, wo man diese Zweier-Bitgruppen im 8- oder 16-Bit-Wort hinpackt, eher vorne oder eher hinten, und das womöglich bei verschiedenen Befehlsgruppen unterschiedlich. Deshalb sehe ich diese Ebenen als unabhängig an und keine Artikelredundanz gegeben, um zum eigentlichen Ausgangspunkt zurückzukehren. --PeterFrankfurt 21:05, 23. Nov. 2010 (CET)

text: Ach von genau diesen Designentscheidungen sprichst Du schon die ganze Zeit... Die haben doch mit dem Konstruktionsprinzip und schon gar nichts mit "einem Weg hin zu Mnemonics" oder "eher vorne oder eher hinten" zu tun. Das sind spezielle Entscheidungen, die natürlich nicht auf jede einzelne Ausführung zutreffen und dennoch das Prinzip nicht berühren. Du hast doch wegen des Dampfmaschinenmodells in der Schule nicht auch die ganze Zeit geglaubt, es gibt nur Dampfmaschinen mit genau einem stehenden Zylinder, 20 Kubik Hubraum und rotem Pleuel. Also hat das Ding doch gereicht, um Dir das Prinzip vorzuführen und Du erkennst eine Dampfmaschine, auch wenn sie in einer Lok verbaut ist. Es geht nicht um eine statistische Erhebung, wieviele Opcodes im 3. Bit einen Zero-Branch codieren (vieviele Dampfmaschinen eine rote Pleuelstange haben). Ich befürchte, es ist hoffnungslos. --Mihalog 22:57, 23. Nov. 2010 (CET)
replies: text:  Aber so ein Prinzip ist doch ein bisschen arg beschränkt, wenn man einfach dem wirklich naheliegenden Gedanken folgt, dass numerierte Register sich in zusammenhängenden Bitgruppen irgendwo im Opcode niederschlagen könnten. Das ist trivial und und kann mal am Rand erwähnt werden. Es reicht aber nicht zu einem alles erklärenden Prinzip. - Wie gesagt, anfangs ging es um die Frage der Redundanz, und darauf sollte die Argumentation hinauslaufen. --PeterFrankfurt 01:37, 24. Nov. 2010 (CET)

text: Ich habe das Beispiel dem Niveau der Diskussion angepasst. Ich halte den Gesamtkomplex trotzdem für nicht trivial und eine prinzipielle Beschreibung für angemessen. Ich habe leider keine weitere Zeit, mich mit Deinen Sprach- und Verständnisproblemen im Bezug auf das Wort Prinzip auseinanderzusetzen. Dein hätte, könnte und sollte zeigt, dass Du - diplomatisch gesprochen - nicht im Thema bist, also schließe ich hier für meinen Teil ab: das Prinzip gehört in den Abschnitt zum Opcode und der Opcode als Hardware-Software-Schnittstelle letztendlich zum Prozessor. Ende der Durchsage. --Mihalog 09:00, 24. Nov. 2010 (CET)
thread_title:  Überarbeiten 

message: Dieser Artikel könnte durchaus mit dem Artikel Befehlsdecoder zusammengelegt und dort ergänzt werden.
--Mihalog 13:10, 18. Nov. 2010 (CET)
replies: text: Das würde eine Redundanz bedeuten. Das sehe ich aber nicht so: Jener Artikel beschreibt die hardwaremäßige Implementierung dessen, was eher als Konzept und als Softwareaspekt in diesem Artikel hier beschrieben wird. Das ist in meinen Augen schon eigenständig genug. --PeterFrankfurt 02:23, 19. Nov. 2010 (CET)
replies: text: 1. Definiere bitte "Softwareaspekt". 2. Was nutzt der Opcode ohne Befehlsdekoder und umgekehrt? Wo ist die Eigenständigkeit beider Konzepte? --Mihalog 09:52, 19. Nov. 2010 (CET)
replies: text: Es geht nicht darum, wer wem nutzt, sondern wer was macht. Und der eine ist die Hardware (der Befehlsdecoder) und der andere die Software (der Befehlssatz). Letzterer dient als Abstrahierung für den menschlichen Programmierer und Programmleser. Sieh Dir als Beispiel die Befehlssätze von 8080 und Z80 (bei letzterem nur den 8080-identischen Teil) an: Sie machen dasselbe, die Hardware dafür ist die selbe, aber die Befehlssätze sind extrem unterschiedlich, wo der 8080 Befehle wie LDA, STA und MOV kennt, spricht der Z80 übergreifend von LD. Das ist also von der Hardwareimplementierung komplett losgelöst und separat zu betrachten. --PeterFrankfurt 02:00, 20. Nov. 2010 (CET)
replies: text: Wovon Du sprichst nennt man Mnemonic, das ist eine menschenlesbare Form des Opcodes. Ich schlage vor, dass Du Dich vielleicht lieber dort einbringst. Der Opcode bleibt nach wie vor die programmierbare Beschaltungsvorgabe und ist damit genau die Schnittstelle zwischen Hardware und Software. Welche Mnemonics sich ein Prozessor-Konstrukteur für die Assemblersprache seines Prozessors ausdenkt hat exakt nichts mit der Technik zu tun. --Mihalog 15:56, 21. Nov. 2010 (CET)
replies: text: Unter "Befehlssatz" verstehe ich aber das, was in einem Handbuch als zur Verfügung stehende Befehle aufgelistet ist. Wie der Hersteller die Befehle in zusammengehörigen Gruppen sortiert, hat auch was mit der technischen Realisierung zu tun und ist nicht nur eine textliche Geschmackswahl. --PeterFrankfurt 00:13, 22. Nov. 2010 (CET)
replies: text: Es geht ja auch um den technischen "Opcode" und nicht den Assembler-"Befehlssatz". Du bringst da zwei Sachen durcheinander, die zwar zusammenhängen, aber konzeptionell zu trennen sind. Der Mnemonic, also der "Befehl" in Deinem Verständnis ist sogar ausschließlich eine Geschmackswahl, der Opcode ist als Beschaltungsvorgabe technisch bedingt. Ich neige ja nicht zu Buchempfehlungen zur Diskussionsverkürzung, aber bitte besorge Dir mal "Hennessy & Patterson: Computer Architecture", da stehen echt eine Menge wissenswerter Sachen zum Thema drin. Ist ja nicht so, dass ich selbst Dich belehren wollte. --Mihalog 01:06, 22. Nov. 2010 (CET)
replies: text: Seufz, denk Dir, ich weiß, was ein Mnemonic ist. Aber davon sprach ich ja auch gar nicht. Ich sprach von einer (logischen) Gruppierung von Befehlsgruppen/-familien (also was sich in bestimmten gemeinsamen Bitmustern niederschlagen könnte/müsste), die primär in der Hardware realisiert wird, sich dann aber auch in der textlichen Beschreibung wiederfindet. Wenn nun wie bei Z80 vs. 8080 völlig verschiedene Mnemonics (und vor allem deren Gruppierungen bei LD vs. LDA/STA/MOV) vorkommen, legt das für mich nahe, dass auch die interne Hardwarerealisierung unterschiedlich sein könnte. --PeterFrankfurt 01:33, 22. Nov. 2010 (CET)
replies: text: Schluchz. Ich glaube Dir. Aber da Deine Antwort im vorwiegenden Konjunktiv verfasst ist, lass es uns dabei belassen: dieser Artikel behandelt den Opcode, ein anderer den Mnemonic und ein dritter Assembler (auch eine recht prinzipielle Bezeichnung für lesbare Maschinensprachen; wie die sich da wohl einig werden...). Da möglicherweise CPU- und Hardware-Design im Allgemeinen nicht Dein erster Broterwerb sind, schlage ich direkt für heute abend als geeignete Lektüre vor: http://www.intel.com/about/companyinfo/museum/exhibits/4004/docs.htm . Finde ich zumindest großartig. (Oder alle Werke von Rodnay Zaks). --Mihalog 02:05, 22. Nov. 2010 (CET)
replies: text: Ja, schöner Link. Und? Willst Du andeuten, dass alle Prozessoren genau so wie der 4004 strukturiert sind? Beachte bei ihm auch das Detail, dass bei manchen Sprungbefehlen schon die zweite Hexziffer Teil der Sprungzieladresse ist. Also auch hier gibt es kein einheitliches Prinzip, wie sich das Codebitmuster auf die Funktion übersetzt. Mein Reden. Und nein, ich habe noch keinen Prozessor konstruiert, nach intensiver Benutzung von 8085 und 6502 (zu Anfang per Handassemblierung) hatte ich aber diverse Gedanken, wie ich es gerne hätte noch ein bisschen besser machen wollen... --PeterFrankfurt 01:55, 23. Nov. 2010 (CET)
replies: text: Nein das will ich nicht, das ist doch auch Unsinn. Das war dazu gedacht, Dir ein Beispiel für eine sehr einfache Konstruktion zu geben. Ich muss wohl mal klarstellen, dass wir von unterschiedlichen Richtungen auf den Opcode schauen. Von oben, von der Programmierung aus ein Prinzip, oder genauer: eine Kategorie zu suchen hat natürlich überhaupt keinen Zweck. Da bin ich Deiner Meinung, das meine ich aber gar nicht. Die Frage ist nach wie vor, wie ein Opcode (bottom up) entsteht und lass es mich nochmal versuchen: die Opcodes ergeben sich aus der Prozessorkonstruktion. Es geht nicht darum, WO welche Bits im Opcode welche Funktion steuern, sondern WARUM sie da sind. Mein Beispiel der ALU gilt immernoch, obwohl das sehr stark vereinfacht ist. (1) Konstruiere eine einfache ALU mit meinetwegen Volladdierer und drei booleschen Operationen. (2) Wieviele Steuerleitungen brauchst Du? Genau: zwei. (3) Wie lauten die Opcodes? Auch richtig: kommt drauf an, in welcher Reihenfolge der Selektor am hinteren Ende der ALU die Funktionseinheiten ausführt, aber vermutlich erstmal 00,01,10,11 (0,1,2 und 3). (4) Wie weiß die ALU, was sie verarbeiten soll? Du gibst ihr einen Tipp: hast Du z.B. vier Register, dann codierst Du natürlich 00-11 (0-3) und gibst zwei Register für die Operation an. Durch einen Selektor werden die Registerinhalte aus dem entsprechenden Latch auf die ALU geschaltet. Als Opcode ergibt sich mithin für eine Operation 2 mit Registern 0 und 3 z.B. "100011", also "35" oder "$23" und vielleicht "ADD 0,3" als Mnemonic. (5) Um jetzt noch eine Variante zu bringen, definierst Du nicht einzelne Register, sondern Paare und codierst (00,01,10,11) für (0,1),(0,2),(0,3),(1,0). Das vermindert zwar die Möglichkeiten, verkürzt aber den Opcode (Designentscheidung). Die Registerauswahl wird dann nicht direkt auf einen Selektor geschaltet, sondern muss vorher de-multiplext werden. Die gleiche Operation von eben hätte dann den Opcode "1010" und hieße immernoch "ADD 0,3". Dieses Vorgehen ist PRINZIPIELL immer so. Und damit zurück zur Eingangsfrage dieses Abschnittes: ist der Opcode als Konzept eigenständig? Ich finde nicht. --Mihalog 13:58, 23. Nov. 2010 (CET)
replies: text:  Und siehst Du, genau von diesen Designentscheidungen, wie Du sie zwischendrin erwähnst, rede ich. Da gibt es auf Hardwareebene mehrere verschiedene Wege der Implementierung und *unabhängig* davon gibt es auf der Abstraktionsebene hin zu Mnemonics mehrere Wege, die Bitmuster zu offiziellen Befehlen zusammenzudefinieren. Im Opcode gibt es zusätzlich noch die Designentscheidungen, wo man diese Zweier-Bitgruppen im 8- oder 16-Bit-Wort hinpackt, eher vorne oder eher hinten, und das womöglich bei verschiedenen Befehlsgruppen unterschiedlich. Deshalb sehe ich diese Ebenen als unabhängig an und keine Artikelredundanz gegeben, um zum eigentlichen Ausgangspunkt zurückzukehren. --PeterFrankfurt 21:05, 23. Nov. 2010 (CET)

text: Ach von genau diesen Designentscheidungen sprichst Du schon die ganze Zeit... Die haben doch mit dem Konstruktionsprinzip und schon gar nichts mit "einem Weg hin zu Mnemonics" oder "eher vorne oder eher hinten" zu tun. Das sind spezielle Entscheidungen, die natürlich nicht auf jede einzelne Ausführung zutreffen und dennoch das Prinzip nicht berühren. Du hast doch wegen des Dampfmaschinenmodells in der Schule nicht auch die ganze Zeit geglaubt, es gibt nur Dampfmaschinen mit genau einem stehenden Zylinder, 20 Kubik Hubraum und rotem Pleuel. Also hat das Ding doch gereicht, um Dir das Prinzip vorzuführen und Du erkennst eine Dampfmaschine, auch wenn sie in einer Lok verbaut ist. Es geht nicht um eine statistische Erhebung, wieviele Opcodes im 3. Bit einen Zero-Branch codieren (vieviele Dampfmaschinen eine rote Pleuelstange haben). Ich befürchte, es ist hoffnungslos. --Mihalog 22:57, 23. Nov. 2010 (CET)
replies: text:  Aber so ein Prinzip ist doch ein bisschen arg beschränkt, wenn man einfach dem wirklich naheliegenden Gedanken folgt, dass numerierte Register sich in zusammenhängenden Bitgruppen irgendwo im Opcode niederschlagen könnten. Das ist trivial und und kann mal am Rand erwähnt werden. Es reicht aber nicht zu einem alles erklärenden Prinzip. - Wie gesagt, anfangs ging es um die Frage der Redundanz, und darauf sollte die Argumentation hinauslaufen. --PeterFrankfurt 01:37, 24. Nov. 2010 (CET)

text: Ich habe das Beispiel dem Niveau der Diskussion angepasst. Ich halte den Gesamtkomplex trotzdem für nicht trivial und eine prinzipielle Beschreibung für angemessen. Ich habe leider keine weitere Zeit, mich mit Deinen Sprach- und Verständnisproblemen im Bezug auf das Wort Prinzip auseinanderzusetzen. Dein hätte, könnte und sollte zeigt, dass Du - diplomatisch gesprochen - nicht im Thema bist, also schließe ich hier für meinen Teil ab: das Prinzip gehört in den Abschnitt zum Opcode und der Opcode als Hardware-Software-Schnittstelle letztendlich zum Prozessor. Ende der Durchsage. --Mihalog 09:00, 24. Nov. 2010 (CET)
thread_title:  Redundanz?