Diskussion:Befehlsdecoder
Wäre doch mal ganz nett wenn mir jemand erklären könnte wie ein solcher Befehlsdecoder es fertig bringt die Befehle überhaupt zu verstehen.
Hab den Artikel mal etwas erweitert, hoffe ich bin dabei nicht übers Ziel hinausgeschossen und hab mit zu vielen Details/Infos verwirrt. Etwas Feedback zur Verständlichkeit wäre nett. Typos und Groß-/Kleinschreibung bitte auch korrigieren ;-)
Vielleicht kann mir jemand der auch vom Fach ist noch seine Meinung zu der Bezeichnung des Befehlsdekoders als Interpreter kundtun. Mit ist der Zusammenhang an dieser Stelle nicht klar, ich würd das streichen.
Und letztlich die Frage Dekoder mit k oder mit c zu schreiben. Da es das Deutsche Wort dekodieren gibt würd ich für k plädieren (es gibt auch Kode mit k...) Meinungen? Cheers -- SID6.8 00:18, 3. Okt 2006 (CEST)
- Die Bezeichnung als Interpreter kann man als Veranschaulichung sicher so stehen lassen, obwohl sie technisch gesehen m.E. nicht ganz den richtigen Betrachtungswinkel hat. Es ist ja nicht so, dass der Dekoder das Befehlswort hernimmt und feststellt, dass es sich um eine Addition zweier Register handelt. Die Interpretation ist mehr impliziter Natur, weil ein Teil des Befehlswortes auf den Funktions-Selektor der ALU gelegt wird und die "Addition" auswählt, die Registerinhalte über eine Selektorschaltung auf die ALU-Eingänge gelegt werden und dadurch im nächsten Takt eben die durch das Befehlswort beschaltete Operation abläuft. Das Thema ist eng verwandt mit dem Befehlszyklus, wobei das Beispiel oben ausschließlich die "execute"-Phase benötigt. Speicherzugriffe jedoch werden in weiteren Phasen der Befehlsausführung vor- bzw. nachbereitet.