Diskussion:Opcode

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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)[Beantworten]

Überarbeiten[Quelltext bearbeiten]

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)[Beantworten]

Stimmt nicht. Ist flüssig zu lesen. --Musbay 22:16, 15. Jul. 2009 (CEST)[Beantworten]
Argument "Maschinen-Übersetzung" kann ich ebenfalls nicht nachvollziehen, Baustein daher wieder entfernt. Gruß --Howwi 10:04, 2. Aug. 2009 (CEST)[Beantworten]

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)) [Beantworten]


(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)[Beantworten]
'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)[Beantworten]



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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

Selbstverständlich. Der Opcode stellt exakt das Bitmuster auf dem Bus dar,welches die internen Logikbausteine gemäß der digitalen Logik zu den entsprechenden Aktionen veranlaßt. Dies ist Prinzip. --95.89.45.3 04:31, 20. Feb. 2011 (CET)[Beantworten]

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)[Beantworten]
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)[Beantworten]
"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)[Beantworten]
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)[Beantworten]

Redundanz?[Quelltext bearbeiten]

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

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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]

Artikelschutz[Quelltext bearbeiten]

Ich habe den Artikel wegen einer VM wegen EditWars geschützt, und das bleibt jetzt erst mal so, bis mir einer erklärt, was Programmiercodes mit Gedächtnistechniken wie Mnemotechnik zu tun haben sollen. Auch in der Begriffsklärung Mnemonic wird das auseinandergehalten. Die Mnemotechnik hat etwas mit Gedächtnistraining bei Menschen (und auch bei Tieren) zu tun, aber doch nicht bei Programmiercodes, höchstens weit entfernt bei Künstlicher Intelligenz. Ich lass mich da gerne aufklären, wenn es das Problem löst. Danke, – Doc TaxonDisk.Wikiliebe?! 07:41, 14. Okt. 2018 (CEST)[Beantworten]

@Mirer, RoBri, Majo statt Senf: die IP hatte recht. Mnemonic war vorher richtig nach Assembler verlinkt. Wäre schön wenn ihr das richtig stellen lassen würdet. -- 2003:DE:724:CE7C:1D2E:3FAD:7B07:EE92 08:09, 14. Okt. 2018 (CEST)[Beantworten]
Okay. Mir gings primär um den typischen EW der Sperrumgehung. --Roger (Diskussion) 08:35, 14. Okt. 2018 (CEST)[Beantworten]
Aha, es ging Dir also darum, einen für Dich typischen Editwar zu führen. Danke für das Geständnis. Du hast also per Editwar x-fach offensichtlichen Bullshit in den Artikel eingefügt. Das nennt man Vandalismus. Ich verlange hier entweder eine Begründung für Deine Bearbeitungen oder eine Entschuldigung Deinerseits in Verbindung mit einer Unterlassungserklärung für die Zukunft. Sollte beides ausbleiben, ist eine Benutzersperre einzusetzen. -- 2A02:120B:2C03:C260:20A9:97C:63E1:B8EC 09:50, 14. Okt. 2018 (CEST)[Beantworten]
Danke Roger. @Majo statt Senf: und wie siehst Du das als Beteiligter? – Doc TaxonDisk.Wikiliebe?! 09:16, 14. Okt. 2018 (CEST)[Beantworten]

Assembler ist dirket im Satz danach (korrekt und erkennbar) verlinkt. Wer mit dem Begriff Mnemonic nichts anfangen kann, dem hilft auch der Assembler-Artikel nicht wirklich weiter - der von mir verlinkte Artikel hingegen schon. Mann kann aber auch zweimal direkt hintereinander (einmal verdeckt und einmal verständlich) auf einen wenig hilfreichen Artikel verlinken. Dann weiß der Experte weiterhin worum es geht und die Oma schau - wie hier immer öfter üblich - in die Röhre. --mirer (Diskussion) 02:13, 15. Okt. 2018 (CEST)[Beantworten]

"Wer mit dem Begriff Mnemonic nichts anfangen kann, dem hilft auch der Assembler-Artikel nicht wirklich weiter - der von mir verlinkte Artikel hingegen schon." Bitte führe doch hier mal aus PA und Unterstellung entfernt. --mirer (Diskussion) 15:59, 15. Okt. 2018 (CEST) inwiefern das zutrifft (i.e. was das dem Leser helfen soll) und leiste die vom vorgenannten Benutzer verlangte Aufklärung. -- Salkshirt (Diskussion) 11:32, 15. Okt. 2018 (CEST)[Beantworten]
Das habe ich schon, Unverschämtheiten und Unterstellungen helfen da auch nicht weiter.
Der (nach wie vor drei Zentimeter später verlinkte) Assembler-Artikel erklärt das für Fachleute schon ganz verständlich. Er verlinkt für Leute, denen der Begriff schwer zugänglich ist, aber selbst an zwei Stellen dann den von mir hier verlinkten Artikel der einem den Ursprung und die (leicht anderen) Bedeutungen näherbringt ohne sich in technischen Einzelheiten zu verlieren.
Ich habe ja nichts gelöscht, lediglich klare Linkziele (die im einen Zielartikel exakt so genutzt werden) eingefügt, die beide nebeneinander dem Leser weiterhelfen können. Ändert es doch einfach wieder auf den Pipelink zu Assembler (zwei mal innerhalb der zehn Wörter - ein Meisterwerk der Verlinkung) und alle "Fachleute" sind glücklich.
Ich hielte auch eine Verlinkung auf die BKL für sinnvoll - auch diese Auflistung der Bedeutungen lässt leicht(er) erkennen worum es geht und wo der Begriff herkommt.
Nur bitte ich den hier inhaltlich diskutierenden Admin sich administrativ ab jetzt rauszuhalten. --mirer (Diskussion) 15:57, 15. Okt. 2018 (CEST)[Beantworten]
Du hast es offensichtlich nicht begriffen. Zum Mitschreiben: Der verlinkte Begriff Mnemonic hat mit dem Zielartikel Mnemotechnik genau gar nichts zu tun. Das hat Dir Benutzer:Doc Taxon schon im Eingangspost dieses Abschnitts mitgeteilt, aber es scheint immer noch nicht ganz bei Dir angekommen zu sein. Einen Begriff auf etwas zu verlinken, was mit dem Begriff genau gar nichts zu tun hat, erscheint jetzt nicht unbedingt sehr sinnvoll, findest Du nicht auch? Ja, Du hast nichts gelöscht, Du hast nur eine Bullshit-Verlinkung eingefügt. Und auf Begriffsklärungen wird eigentlich normalerweise nicht gelinkt, weil der Leser oder die Leserin sich dann selbst aussuchen muss, was es denn nun sein soll. In diesem Fall lässt sich das Problem sehr einfach lösen, indem die Verlinkung gelöscht wird, zumal die Bedeutung ja gerade in demselben Satz erklärt wird. Der Vorschlag, wieder auf Pipelink zu Assembler zu ändern, wäre aber ebenfalls gangbar. -- Salkshirt (Diskussion) 17:50, 15. Okt. 2018 (CEST)[Beantworten]
Bist ja immer noch nicht gesperrt. Das Nachschleichen gespickt mit den PAs wie hier (in einen Bereich der dich nicht interessiert und von dem du keine Ahnung hast - siehe ersten Satz) sind zwei der vielen Gründe, warum du als "Astrotroll" hier infinit gesperrt bist und deine Mitarbeit nicht erwünscht ist. Daran wird sich wohl auch nichts ändern, wie du hier wieder schön demonstrierst. --mirer (Diskussion) 20:17, 15. Okt. 2018 (CEST)[Beantworten]
Wie wär's zur Abwechslung mal mit Argumenten, statt mit solch plumpem Getöse? Du warst oben aufgefordert, zu begründen, inwiefern die Verlinkung auf den Artikel Mnemotechnik dem Leser beim Verständnis des Begriffs Mnemonic hilft. Solltest Du dem nicht nachkommen, werden wir hier ganz schlicht davon ausgehen, dass eine solche Begründung nicht existiert. -- Salkshirt (Diskussion) 21:50, 15. Okt. 2018 (CEST)[Beantworten]
Das habe ich, du kannst oder willst damit nur nichts anfangen. Nicht schlimm - man kann und muss hier nicht alles verstehen. --mirer (Diskussion) 22:47, 15. Okt. 2018 (CEST)[Beantworten]

Okay, zusammenfassend bin ich der Meinung, dass das jetzt geklärt ist. Ich gebe den Artikel damit frei und nehme die Mnemotechnik raus. Danke an alle Beteiligten, auch wenn leider die Wortwahl nicht die beste war. – Doc TaxonDisk.Wikiliebe?! 18:33, 16. Okt. 2018 (CEST)[Beantworten]

Ich halte hier gar nichts für geklärt (weiß auch nicht wie man darauf kommen kann) und das du als Admin das inhaltlich entscheidest, nachdem du inhaltlich beteiligt warst, zeigt mal wieder dein grenzenloses Selbstvertrauen bei völliger Regelunkenntnis.
Einen Begriff wie "Mnemonic" in einem Artikel nicht zu verlinken zeugt von der Arroganz der bereits Wissenden. Dann bitte auch in allen anderen Artikel so besserwisserisch handeln und den Begriff entlinken - wobei, vielleicht hat's der Schweizer "Kollege" ja schon lange erledigt. --mirer (Diskussion) 02:18, 17. Okt. 2018 (CEST)[Beantworten]
dann erklär mir doch mal, was Mnemotechnik mit mnemonic im Sinne von Assembler zu tun hat? – Doc TaxonDisk.Wikiliebe?! 03:16, 17. Okt. 2018 (CEST)[Beantworten]