Definitionen und Standards zu ASM Adressierungen, Syntax und Mnemonics [OT aus 'Assembler Tricks']

Zitat von zrs1

Die Instruktion ist der Opcode, nicht der Mnemonic. Mnemonics werden gewählt. Wenn du mir erklären kannst, nach welcher Logik "Inkrementieren" verschiedene Mnemonics braucht, "Schieben" aber nicht, dann hast du ein Argument. Ansonsten gilt nur: in Beiden Fällen existieren Opcodes, die sich implizit (sic!) auf ein Register beziehen, und solche, die sich auf Speicheradressen beziehen.

Implizit mathematisch: Eine eineindeutige Abbildung zwischen Mnemonic und Opcode.
Implizit praktisch: Wenn der Parser des Assemblers nach dem Lesen des 3. Buchstabens des Mnemonics alle Informationen hat, um den Opcode festzulegen.

Was die Wahl der Mnemonics angeht, kann ich mir auch übersichtlichere Schemata vorstellen, als MOS sie gewählt hat.

Ich hätte z.B. INC X, INC Y, INC Adresse usw. schöner gefunden.
Aber solange sie mathematisch einwandfrei sind, und das sind sie, kann ich damit leben.

Zitat von zrs1

Ehrlich gesagt stützt das doch meinen Standpunkt? In dem Fall könntest du jetzt gleich noch zwei Adressierungsarten erfinden (X und Y, super!) Oder eben es einfach dabei belassen, dass das alles implizit ist. Letztlich auch hier eine Benennungsfrage, aber mehr als einen "netten Namen" hat "Akkumulatoradressierung" eben nicht zu bieten -- es ist auch nur implizit

Warum bestehst du darauf die in der Informatik definierten Adressierungsarten umzudeuten ?

Zitat von zrs1

Quelle bitte. MOS hat hier "lustig definiert", nicht ich. "Akkumulatoradressierung" existiert nur genau hier, nicht "in der Informatik".

Diese Adressierungsart heißt in der Informatik allgemein "register direct".
"accumulator" ist ein Spezialfall von "register direct".
Die Adressierungsart "register direct" gibt es bei sehr vielen Mikroprozessoren.
Z.B.: http://service.scs.carleton.ca…_copies/ch5_addrmodes.pdf

Zitat von zrs1

Nur gibt es bei diesen Prozessoren gar keinen implicit addressing mode. Alles was bei MOS implicit heißt ist hier register -- kann man so machen und ist ab einer gewissen Anzahl von Registern sicher auch sinnvoll. Hätte man bei MOS auch so nennen können. Aber den Bezug auf X, Y, S implicit nennen, und nur den auf A anders .. ergibt eben wenig Sinn. Außer wie schon angesprochen eventuell aus Marketinggründen Technisch gesehen ist es das gleiche, under anderem Namen.

Ich gebe auf und ziehe mich aus dem Thema zurück. Von mir aus kann der Thread geschlossen werden.

Vielleicht kann jemand den Thread umbenennen oder verschieben zumindest?
Selbst ohne OT waere es doch etwas arg generisch.

Zitat von zrs1

Wie man das letztendlich in seinem Assembler Source schreibt ist mir wirklich völlig egal ... wollte ja nur mal bei dieser Akkumulatoradressierung ein wenig auf den Zahn fühlen

Das Problem ist, dem Assembler ist es nicht egal, wenn A für ihn ein Label ist, das nicht definiert wurde. Soll man jetzt für globale Labels extra eine neue Konvention schaffen, nur damit diese vier A-Befehle ihr redundantes A mitschleppen dürfen?

Vor gar nicht allzu langer Zeit schickte die NASA eine Sonde für knapp 200 Millionen Dollar zum Mars. Die NASA arbeitet längst mit "ASL", weil ein kohärentes System sinnvoller ist, aber die Firma Lockheed Martin, die fürs Navi zuständig war, meinte, immer noch mit dem veralteten und unakademischen "ASL A" arbeiten zu müssen. So kam es, dass man den Kontakt zur Sonde verlor und die Mission scheiterte. Man munkelt, dass die von der NASA beauftragten Firmen nun auch auf "ASL" setzen, damit nicht nochmal 200 Mio. in den Sand gesetzt werden.

Die Instruktion ist der Opcode, genau. Der Opcode für ASL hat genauso wenig einen Operanden wie INX, nirgends, null, nada -- und genau deswegen bitte auch NICHT in der mnemonischen Darstellung!!!1drölf

Zitat von atomcode

Vor gar nicht allzu langer Zeit schickte die NASA eine Sonde für knapp 200 Millionen Dollar zum Mars. Die NASA arbeitet längst mit "ASL", weil ein kohärentes System sinnvoller ist, aber die Firma Lockheed Martin, die fürs Navi zuständig war, meinte, immer noch mit dem veralteten und unakademischen "ASL A" arbeiten zu müssen. So kam es, dass man den Kontakt zur Sonde verlor und die Mission scheiterte.

Welche Sonde soll das gewesen sein?

Zitat von GenerationCBM

Welche Sonde soll das gewesen sein?

https://de.wikipedia.org/wiki/Schiaparelli_(Marslander)

Nachtrag:
Es war https://de.wikipedia.org/wiki/Mars_Climate_Orbiter

MacBacon, Danke für den Hinweis.

Zitat von oobdoo

Nachtrag:
Es war de.wikipedia.org/wiki/Mars_Climate_Orbiter

Dass der gemeint sein könnte habe ich mir schon gedacht, aber dass da die Wurzel des Übels irgendetwas mit der Verwirrung zwischen ASL/ASL A in Assembler zu tun hätte, wäre mir spontan sehr neu. Aber ich kann ja auch in meinen eigenen Fachgebieten nicht alles wissen und lerne gerne dazu, deswegen hätte ich gerne erklärt bekommen, wo da der Zusammenhang ist. Der Abschlussbericht der Unfalluntersuchung erwähnt jedenfalls absolut nichts dergleichen:
http://sunnyday.mit.edu/accidents/MCO_report.pdf

Zitat von Mac Bacon

Dass MOS die "ASL A"-Notation benutzt hat, dürfte mit dem 6800 von Motorola zusammenhängen. Diese CPU war ja quasi die Vorlage für den 6502, hat aber zwei Akkumulatoren, genannt A und B. Die Befehle "ASL A" und "ASL B" ergaben dementsprechend zwei unterschiedliche Opcodes.
Auf Opcode-Ebene würde ich das dann aber immer noch als implizite Adressierung bezeichnen, einfach weil keine Argumentbytes geholt werden. Aber aus Marketingsicht ist es natürlich gut, wenn im Datenblatt eine möglichst hohe Anzahl von Adressierungsarten genannt werden kann...

Eigentlich nicht, das würde ich eher bezweifeln. 6800, 6809 und Derivate haben A und B für den jeweiligen Akku immer direkt im Mnemonic und nicht als Parameter. Dort heißen die Mnemonics ASLA, ASLB, SUBA, SUBB, usw.

• Man hat sich hier nicht auf 3-Byte-Mnemonics beschränkt (das ist wohl eher eine ästhetische Entscheidung bei den 65xx-Leuten gewesen) und
• A und B am Mnemonic-Ende war bei 68xx bei RWM-Befehlen (ASL, ASR, INC, DEC...) wie auch bei anderen Befehlen konsistent vorhanden, sobald etwas mit dem jeweiligen Akku etwas zu tun war.

@zrs1 Im Gegensatz zum TE bin ich stets gewillt, alle Fragen zu beantworten und auf Argumente einzugehen. Wenn bspw. zu dem Tinkiwinki-Argument geschwiegen wird, denke ich nur "keine Antwort ist auch eine Antwort". Das nennt man dann auch Rosinenpickerei, wenn man einerseits auf kaum akzeptierte Standards pocht, sie andererseits ablehnt, wenn es einem nicht gefällt.

>"Man kann auch Probleme erfinden."
Oder eben Probleme solange mitschleppen, bis man es merkt; siehe Beispiel.

>"Wer Labels mit genau einem Buchstaben vergibt gehört sowieso geschlagen, der darf dann auch ruhig noch etwas mehr "Lehrgeld" zahlen."
Warum? Es ist deine Meinung, spricht aber nicht unbedingt gegen Regeln, und nur um die ging es. Wenn jemandem das nicht passt, muss man die Vereinbarungen ändern, aber solange man sich dran hält, ist alles ok. Allein die Möglichkeit dieser Überlappung von Label und Mnemonik ist maßgebend und wäre in größerem Maßstab bei anderen Dingen evtl. ein großes Risiko. Wegen solcher "Kleinigkeiten" sind schon Raketen abgestürzt.

Dieses Argument erinnert mich auch an den Straßenverkehr: Wer 20% langsamer fährt als er darf, wird weder bzgl. Rechtsprechung noch StVO belangt werden. Aber dennoch lichthupt und schimpft alles hinter dir, weil sie irrtümlich glauben, dass das nicht in Ordnung wäre. Vor allem, wenn ich allein auf der Straße fahre bzw. an dem Programm nur selbst arbeite, bleibt die Handhabung innerhalb der gegebenen Regeln meine persönliche Sache und gefährdet niemanden. Folglich muss ich auch kein Lehrgeld zahlen. Und wenn man nicht allein damit ist: Demjenigen die Schuld zuzuschreiben, der sich innerhalb der Regeln bewegt, wäre verkehrt.

>"Was soll der NASA-Unsinn?"
Eine treffende Analogie sein.

>"Kann ich nach wie vor nicht verstehen, wie man sich über eine Mnemonic-Schreibweise so aufregen kann."
Ich rege mich nicht auf. Ich halte es lediglich für kontraproduktiv und fehlerträchtig, in der Programmierung an Schreibweisen festzuhalten, die schon seit langer Zeit flächendeckend abgelöst wurden, und das hat in der Regel einen guten Grund. Bereits vor mindestens 25 Jahren wurde das im Informatik-Studium für Techn. Informatik implizit gehandhabt. Wenn diese vielen Informatiker es dann alle so schreiben, ist das ein Quasi-Standard, und ein Einzelner, der meint, er muss das dennoch anders machen, hat in dieser Menge keine Chance mit seiner exotischen Meinung, dass das ja die unfehlbaren MOS-Leute ursprünglich anders wollten (Es gibt sicher noch andere und modernere Beispiele als ASL und co). In keinem Buch, keiner Zeitschrift, von keinem User und keiner gängigen Internetseite zum C64/65xx habe ich das jemals so gesehen.

Damit sage ich keineswegs, dass man immer mit dem Strom schwimmen muss. Für sich allein kann jeder arbeiten, wie er will, aber in der Gemeinschaft, die es quasi komplett anders handhabt, bildet man damit einen Störfaktor, sodass bspw. ein ganzer Thread sein eigtl. Ziel verfehlt. Man kann auch versuchen, andere zu überzeugen, aber das scheint bei diesem Thema ja bereits vor vielen Jahren schon gescheitert zu sein; darum frage ich mich, warum man das Jahrzehnte später nochmal wieder einführen muss.
Ich lerne gerade ACME, weil ich festgestellt hatte, dass das hier der Renner ist. Ich könnte ja auch mit dem ollen Giga-Ass weitermachen (siehe lotto.src), der ab dem Sonderheft 35 auch mal ein Renner war und mit dem ich besser vertraut bin als mit dem, was heute üblich ist. Käme in der Gemeinschaft bestimmt gut, zu verlangen, dass sich heute noch jeder wieder darauf einstellt, anstatt sich selbst wenigstens bei dem wichtigsten und verbreitetsten zu integrieren.

>"ASL einmal mit und einmal ohne Operand macht nicht nur die Fehlersuche schwieriger, es verletzt auch grundlegende Erwartungen"
Seltsam, das ist wiederum für mich ein erfundenes Problem. Ich hab bereits viele tausend Zeilen Assembler geschrieben, lange BASIC-Programme meines Bruders in ASM übersetzt, zeitweise 14h täglich und übermüdet, aber nicht einmal hatte ich bei diesen vier Befehlen irgendwas verwechselt oder das Gefühl, dass sie beim Debugging ein Problem darstellen würden. Bisher war mir bei der Eingabe immer bewusst, ob ich am Akku oder einer Speicherzelle werkeln will und schrieb es auch so hin. Zu dieser mutmaßlichen Fehlersuchproblematik bräuchte ich dann schon ein konkretes Beispiel. Ist mir jedenfalls nie untergekommen und hab ich auch noch nie von anderen 6502-Programmieren gehört.

>"dann hätte man sinnvollerweise für die Akku-Schiebereien eigene Mnemonics spendieren müssen, wie beim Inkrementieren von Indexregistern"
Damit könnte ich sogar leben, das heute noch zu ändern. Dürfte @Mac Bacon sofort als alternative Schreibweise einbauen. Das Problem ist, dass dann unmittelbar wirklich alle mitziehen müssten und nicht wieder einer kommt "ja aber die MOS-Leute haben gesagt ..". Das kann man aber genauso vergessen, wie, dass die Mehrheit noch wieder auf die alte Akku-Darstellung umsteigt. Allein dieses ASL vs. LSR fand ich schon immer inkonsequent. Warum nicht wie bei ROL/ROR auch ASL/ASR oder LSL/LSR? Und da man auf das "Arithmetic/Logical" ohnehin pfeifen kann, hätte man konsequent und kohärent gleich SLA (Shift Left A), SRA (Shift Right A), RLA (Rotate Left A) und RRA (Rotate Right A) nehmen sollen.

Ich bräuchte eine Zeitmaschine und ein Blitzdingsgerät; dann würde ich bei MOS Tech. reingehen und den Verantwortlichen und seine Entwürfe aufsuchen, und diese Diskussion würde es nie geben.

>"Also einfach mal die Situation so akzeptieren wie sie ist: "Offiziell" ist es mit "A", aber beide Schreibweisen existieren und werden genutzt."
Und genau das ist das Problem. Deswegen habe ich doch das Beispiel genannt, wozu das im Extremfall führen kann, wenn jeder es so macht, wie er will. Darum geht es in erster Linie und gar nicht mal darum, was "richtiger" ist.
Die NASA akzeptiert die Situation aus gutem Grund nicht mehr.

Übrigens, Aufregung, Verbissenheit, Wut etc. gibt es viel seltener im Forum als man meint. Das sieht oft nur so aus. Man kann über alles reden, seine Meinung begründen oder versuchen, jemanden zu überzeugen, und ist trotzdem dabei total relaxed. Ohne jede Militanz.

@GenerationCBM Selbstverständlich war das nur eine reale Analogie; darum die parallele Problematik (ASL/ASL A) jeweils in Anführungszeichen. Yards, Meilen, mph, Fuß, ft/s, Gallonen, Barrel, Pound, °Fahrenheit und co. Es ging um die Missachtung der SI-Einheiten, den der Löwenanteil der Welt verwendet. Auch England ist weitgehend nachgezogen; die größte Extrawurst braucht nach wie vor die USA. Aber dann heulen, wenn es nicht funktioniert. 200 Mio. $ ist ein schönes Lehrgeld. Bei gemeinsamen Dingen sollte man eben doch mit dem Strom schwimmen, denn sonst funktioniert es nicht. Das ist das Problem, auf das ich hier mit dieser Analogie hinweisen wollte. Wir wollten eigtl. über Assembler Tricks sprechen, und die können mitunter heftig kompliziert sein. Wenn dabei aber zuvor schon keine einheitliche Syntax vereinbar ist, kann man das gleich ganz vergessen. Dann kommt bald der nächste, der wieder was anderes gesehen hat und als Standard erachtet. Keine Firma könnte so funktionieren.

Mein erster Ausbildungsberuf war Maschinenbauzeichner. Es ging also um Maschinenbau und normgerechtes technisches Zeichnen. Man wird überschüttet mit Normen aus DIN, ISO, EN und noch andere. Manchmal bissen sich Normen, oder jemand ist älter und hat es anders gelernt, oder jemand ist jung, gerade ausgebildet und macht es wieder anders -- bei den Arbeitern in der Werkshalle, die die Zeichnungen lesen und verstehen müssen, genauso. Es wurde aber nicht gesagt, dass jeder jede andere Sicht lernen und akzeptieren müsse, sondern es wurde sich betriebsweit (400 Mitarbeiter) auf einen Standard geeinigt, meist auf den etablierten, nicht immer auf den neuesten. In einem Forum scheint das wohl nicht zu funktionieren.

@ Moderation: Gerne auslagern. Titel: "Potentieller Guinness-Rekord für längste Diskussion über die Darstellung eines Assemblerbefehls"

Zitat von atomcode

Das Problem ist, dem Assembler ist es nicht egal, wenn A für ihn ein Label ist, das nicht definiert wurde. Soll man jetzt für globale Labels extra eine neue Konvention schaffen, nur damit diese vier A-Befehle ihr redundantes A mitschleppen dürfen?

Alle meine Assembler-Quelltexte enthalten ASL A, weil das zu Vor-C64-Zeiten nummal die von MOS vorgegebene Standard-Notation war. Ein Assembler der sich an diesen Standared nicht hält oder diesen nicht versteht, ist für mich eigentlich nicht einsetzbar (sowohl aus praktischen als auch aus fundamentalreligösen Gründen).

Dass A als Hex-Zahl interpretiert wird, kann ja nicht sein, weil bei jedem Assembler mit ordentlicher Syntax eine Hexzahl eindeutig mit $ oder 0x eingeleitet wird.
Alles andere führt zwangsläufig zu Fehlinterpretation, die ich dann mühsam suchen müsste.
Und A als Label kann auch nicht sein, weil A ein reserviertes Schlüsselwort ist.

Ich wollte eigentlich auf einen neueren Assembler umsteigen, aber wenn ich das hier so lese, dann bleibe ich wohl doch erst mal bei meinem Assembler mit strikter Syntax und MPS-kompatiblen Mnemoics.