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

Es gibt 58 Antworten in diesem Thema, welches 16.962 mal aufgerufen wurde. Der letzte Beitrag (5. Mai 2018 um 17:23) ist von atomcode.

  • 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.

  • Code
    Die HuC6280 CPU hat sowas wie 'inc a' ;-)

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • 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.

  • Ich hĂ€tte z.B. INC X, INC Y, INC Adresse usw. schöner gefunden.

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

    Wie kommt man ĂŒberhaupt auf eine solche Diskussion? 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 :D

  • 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 ?

  • in der Informatik definierten Adressierungsarten

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

    edit: eine kurze Suche fördert ĂŒbrigens ein Buch zutage, das die Akkumulatoradressierung als einen Sonderfall der impliziten Adressierung fĂŒhrt. Das klingt so weit korrekt :) (auch interessant dabei: Alle Opcodes mit impliziter Adressierung, also Akkumulator eingeschlossen, haben Bit 3 gesetzt)

  • 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.: Bitte melde dich an, um diesen Link zu sehen.

  • Die Adressierungsart "register direct" gibt es bei sehr vielen Mikroprozessoren.
    Z.B.: service.scs.carleton.ca/sivara
_copies/ch5_addrmodes.pdf

    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.

  • 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.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Sicher könnte man diesen "Ausflug" auslagern, der IMHO darauf hinauslĂ€uft: "Richtig" ist, was der Hersteller definiert -- aber deswegen noch lange nicht in sich logisch ;) Die Fakten dazu sind ja alle genannt und es wird wohl keiner mehr komisch gucken, wenn er in irgendeinem Code asl a resp. asl sieht.

  • 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 :D

    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

  • 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?

  • Welche Sonde soll das gewesen sein?

    Bitte melde dich an, um diesen Link zu sehen.

    Nachtrag:
    Es war Bitte melde dich an, um diesen Link zu sehen.

    MacBacon, Danke fĂŒr den Hinweis. :)

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wÀre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

    Einmal editiert, zuletzt von oobdoo (3. Mai 2018 um 01:38)

  • 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?

    Man kann auch Probleme erfinden. Wer Labels mit genau einem Buchstaben vergibt gehört sowieso geschlagen, der darf dann auch ruhig noch etwas mehr "Lehrgeld" zahlen.

    Was soll der NASA-Unsinn? Kann ich nach wie vor nicht verstehen, wie man sich ĂŒber eine Mnemonic-Schreibweise so aufregen kann. Und nein, auch deine Logik ist nicht die "einzig wahre". ASL einmal mit und einmal ohne Operand macht nicht nur die Fehlersuche schwieriger, es verletzt auch grundlegende Erwartungen -- dann hĂ€tte man sinnvollerweise fĂŒr die Akku-Schiebereien eigene Mnemonics spendieren mĂŒssen, wie beim Inkrementieren von Indexregistern.

    Die Situation ist nicht ganz logisch, so oder so. Ja, mit der "Akkumulatoradressierung" hat man einen Sonderfall erfunden, den es so auf Instruktionsebene nicht gibt. Einfach das A in der Assemblerschreibweise wegzulassen fĂŒhrt aber zu anderen Inkonsistenzen. Also einfach mal die Situation so akzeptieren wie sie ist: "Offiziell" ist es mit "A", aber beide Schreibweisen existieren und werden genutzt.

  • 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:
    Bitte melde dich an, um diesen Link zu sehen.

  • 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... :anonym

    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.
  • Bitte melde dich an, um diesen Link zu sehen. 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 Bitte melde dich an, um diesen Link zu sehen. 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. :motz: Ohne jede Militanz. :kill:

  • Bitte melde dich an, um diesen Link zu sehen. 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" Bitte melde dich an, um dieses Bild zu sehen.

  • 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.