Diskussion:Opcode

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)

Überarbeiten

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)

Stimmt nicht. Ist flüssig zu lesen. --Musbay 22:16, 15. Jul. 2009 (CEST)

Argument "Maschinen-Übersetzung" kann ich ebenfalls nicht nachvollziehen, Baustein daher wieder entfernt. Gruß --Howwi 10:04, 2. Aug. 2009 (CEST)

Gibt es eigentlich Interesse, die verschiedenen Opcodes der bisherigen (aller?) Microprozessoren hier zu archivieren ? Könnte sich in der fernen Zukunft mal als nützlich erweisen - wenn alte Maschinen mit alten Daten wiederbelebt werden sollen ;-) So in 100-200Jahren ... /HB 2009-12-20 (nicht signierter Beitrag von 93.232.201.173 (Diskussion | Beiträge) 21:07, 20. Dez. 2009 (CET))

---

(Bitte neue Punkte unten anfügen, nicht mittendrin) Mir fehlt eine Legende zu den Lochstreifencodierungen beim Zuse Z3. Lochstreifen haben doch nur zwei Zustände: gelocht oder nicht gelocht - oder? Wiso gibt es da 3 Zeichen ? '-','.','o' ... Wie ist 'Z' Codiert ?

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)

---

Wichtig wäre in diesem Artikel zu allererst eine Beschreibung, wie sich ein Opcode ergibt. Es ist doch so, dass es sich um eine direkte Abbildung der binären Eingangs-Schaltzustände eines Prozessors handelt, mit denen Funktionen ausgewählt werden. Das hat mit Datenübertragung erstmal nichts zu tun. Die Signalisierung bei einer ALU ist im Prinzip ein Opcode. --Mihalog 23:25, 17. Nov. 2010 (CET)

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)

Doch kann man. Natürlich sind die spezifischen Steueraufgaben der einzelnen Bits unterschiedlich, aber es geht doch unter der Überschrift "Opcode" offensichtlich um das Prinzip und das ist immer gleich. Und da ist es übrigens auch egal, ob die Selektor-Gatter in TTL, PLA, Microcode oder sonstwie ausgeführt sind. --Mihalog 11:37, 18. Nov. 2010 (CET)

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)

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)

"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)

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)

Redundanz?

Dieser Artikel könnte durchaus mit dem Artikel Befehlsdecoder zusammengelegt und dort ergänzt werden. --Mihalog 13:10, 18. Nov. 2010 (CET)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Nein das will ich nicht, das ist doch auch Unsinn. Das war dazu gedacht, die 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 1 und 3 z.B. "100111", also "39" oder "$27" und vielleicht "ADD 1,3" als Mnemonic. Noch Fragen? --Mihalog 09:40, 23. Nov. 2010 (CET)