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

Quote from atomcode

Selbstverständlich war das nur eine reale Analogie;

Sorry, aber das ist weder so wirklich ersichtlich (lies: man läuft Gefahr, das geschriebene für bare Münze zu nehmen), noch halte ich den MCO-Fall da für eine Analogie geeignet, denn die Fehlerproblematik dort ist wesentlich komplexer als dass sie sich mit der gern genommenen volkstümlich-wohlfeilen Vereinfachung "böh, sind die blöd, benutzen die falschen Einheiten" abdecken liesse. Die Lehre aus MCO ist viel näher an "unterschiedliche Einheiten werden nur dann zum Problem, wenn die sowieso vorgesehene Umrechnung an einer Schnittstelle aus (systemisch-menschlichen Gründen) ausfällt und die Überprüfung und Fehlerkorrektur aus (anderen systemisch-menschlichen Gründen) nicht greift", was vermutlich eher das Gegenteil von dem ist, was du argumentieren willst.

Quote from atomcode

Bei gemeinsamen Dingen sollte man eben doch mit dem Strom schwimmen, denn sonst funktioniert es nicht.

Wenn jedem Beteiligten klar ist, dass das wichtige Teil der Opcode ist und die Mnemonics leicht variieren können, würde ich das Problem als einigermassen mitigiert betrachten.

Quote from atomcode

In einem Forum scheint das wohl nicht zu funktionieren.

Ist ja auch schwierig. Foren sind im Internet, und "im Internet rechthaben" ist mitunter so'ne Art Volkssport.

Hat noch keiner ein Plug-In für ASM angefangen? Würde hier jetzt passen

ich bin ja der meinung das ASL A und ASL das selbe meinen und ich kann beide schreibweisen ausnander halten.

man koennte ASL A als "Arithmic Shift Left Accu" uebersetzen und ASL als "Accu Shift Left"
spass beiseite ich verstehe eure diskusion ueberhaupt nicht, jeder solls so schreiben wie sein assembler es versteht.
nichts destotroz sollte man beide "standarts" verstehen.

zu den asm tricks:

bei raster irqs sieht man oft das konstrukt

wenn sich sich sicher sein kann das das V-flag nie gesetzt
wird kann man das kuerzen in dem man stattdessen

nutzt.

salute

Quote from syshack

Was hier an emotionaler Disonanz wegen einer einfachen Definitionssache erzeugt wird, ist einfach Kindergarten-Niveau.
Soll der Thread gleich in Laberecke-->Kindergartenecke?

Koennen wir hier also bitte zurueck zum Topic - Assembler Tricks und Optimierungen - kommen.

Ich weeiß ja nicht, auf wen Du Dich genau beziehst, aber das Bashen auf Flaming-Niveau ist bei einem ernst gemeinsten Post extrem kontraproduktiv. Daher doch bitte vorher genau nachdenken, ob ein Post ein Trolling oder ernst gemeint ist. DAS hilt dem Thread weiter, der keineswegs OT lauft. Ein solcher Plug-In entspräche a) dem Topic "Tricks und Optimierungen" als auch hier speziell dem ASM-Gedanken. Ich bin hier UNTERSTÜTZER und kein HAUSTROLL!

Quote from syshack

@ZeroZero Das war ja auch nicht auf Dich bezogen, sondern auf die Definitionssache weiter oben.
Ich find's einfach immer wieder mühsam, wie hier im Forum interessante Themen und Threads kaputt geofftopiced werden, bis einem die Lust vergeht weiterzulesen oder was Konstruktives beizutragen.

Dann bitte ich um Entschuldigung und werde nur dann etwas sagen, wenn mir direkt ASM-mäßigetwas einfällt!

@GenerationCBM Ich behaupte nicht, dass die blöd sind, sondern stur. Stur wie die Leute, die immer noch ein Viertel Pfund Aufschnitt an der Theke verlangen anstatt 125g. "Die junge Bedienung hat es gefälligst zu wissen, wie viel das ist. Ich muss mich nicht der Mehrheit anpassen. Nach mir die Sintflut!". Dito "sorry", aber zu glauben, in dieser Analogie wäre es tatsächlich ernst gemeint, die würden da noch mit dem 6502 hantieren, und es wäre jetzt wirklich wegen des Befehls verloren gegangen, finde ich etwas albern, zumal das jeder bei Wiki nachlesen kann, wie es war, und da steht dann auch, dass der Hintergrund eben wohl recht trivial ist:
NASA: Impuls p im metrischen Internationalen Einheitensystem (SI) mit der Einheit Ns. Lockheed Martin: Im imperialen System mit der Impulseinheit lbfs, also 4,45 mal so groß. Ende. Und selbst, wenn es viel komplizierter gewesen wäre, ist die Analogie treffend, weil es hier eben auch um die unnötige Verweigerung geht, sich daran zu halten, wie es allgemein anerkannt ist. Was heute akademisch verbreitet ist, ist maßgebend und nicht, was irgendwann in den 70ern oder früher mal erdacht wurde.

Letztes Statement zum ASL-Problem: Das Argument, dass es für ASL verschiedene Adressierungsarten gebe, aber für INX nicht, ist keine Begründung dafür, dass man es bei ASL anders schreiben müsste. Das Argument ist falsch, weil sich hier ausschließlich an der Mnemonik geklammert wird, die man sich einst mal ausgedacht hat und die es nur so aussehen lässt, als wäre das eine eine Gruppe und das andere nicht. Man hätte das ASL auch genauso gut SLA nennen können, und schon fiele es genauso aus dem Rahmen wie INX/INY bei den Inkrementierungsmöglichkeiten. Es ist nur eine Bezeichnung, eine Buchstabenfolge, damit man weiß, worum es geht, mehr nicht. Davon abzuleiten, man müsse das jetzt besonders schreiben, ist Unfug, im wahren Sinne des Wortes, denn es fügt sich nicht den sonstigen Konventionen dieser Mnemonik. Es ist, wie das angloamerik. Einheitssystem, inkohärent. Selbst, wenn man zwei Akkus hätte, würde ich lieber das "arithmetic" implizieren und an der 3-Zeichen-Darstellung festhalten: SLA und SLB oder wegen mir dann 4 Zeichen benutzen, aber eben nicht als Operanden, den es im Code auch nicht gibt. Wofür schafft man erst die 3-Buchstaben-Konvention, wenn man sie dann für nur 4 Fälle wieder bricht, obwohl das nicht mal notwendig wäre? Es gibt Adressierungsarten für die Inkrementierung und zwei implizite dafür. Es gibt Adressierungsarten für die Linksverschiebung und eine implizite dafür; ergo muss letztere keine Extrawurst bekommen. Punkt.

@syshack >"Soll der Thread gleich in Laberecke-->Kindergartenecke?"
Ich hatte ausdrücklich darum gebeten, dass es verschoben wird. Aber wieso bitte in die "Kindergartenecke" bei einem fachspezifischen Thema? Diese Provokation halte ich jetzt eher für emotional. Auch die Reaktion auf @'ZeroZero''s grandiosen Idee, die auch für diesen Thread extrem hilfreich wäre und die OT-Diskussion ebenfalls nicht mehr erforderlich gemacht hätte -- quasi der Zwang zu einem gemeinsamen Standard, wie in der Uni und wie in der Firma. Es entspricht auch nicht der Netiquette, erst etwas negativ zu beurteilen, um dann erst zu fragen, um was es überhaupt geht. Er sagte "ein Plug-In für ASM", und du fragst "Ein Plugin fuer was?" .. Genauso das Abdriften vom Sachlichen ins Persönliche, von wegen "Kindergartenniveau". Tut nicht Not. @'war64burnout' ist auch konsequent und dabei trotzdem nett.

So, liebe ASM-Liebhaber, das war alles, was Sie schon immer über ASL wissen wollten, aber nie zu fragen wagten. Schön, dass wir mal drüber gesprochen haben.

Quote from syshack

ALLERDINGS: Aus Deiner Reaktion und Ausführungen geht für mich jetzt hervor, dass es wahrscheinlich um ein "PlugIn System" handeln soll, welches Assembler Mnemonics also ASL A oder B oder C "the right way" einfügen soll?

Allerdings hatte ich eher ein allgemeineres Plug-In im Sinn, dass mit den vorhandenen Codes für ASM korrekte, wie hier gewünscht, Optimierungen bzw. ASM-Codes bereitstellt, dass genau die benötigten Einflüsse auf den Code ausüben, also, wenn ich es Recht verstanden habe, den ASM-Codemit Regeln versieht, die gewisse Restriktionen beugen kann im Sinne, dass der ASM-Editor Anpassungen an die Compilerregeln bereitstellt, damit gewisse Anforderungen gesetzt werden, aber andere nicht einfließen. Vielleicht geht das ja gar nicht, aber das war mein Hintergedanke, und um Entschuldigung habe ich auch gebeten für meine harsche Antwort. Wenn mein Vorschlag "für'n Arsch" war, dann packt ihn OT und vergesst es einfach.
Ich Blödie: eigentlich gehört das hier in Definitionen und Standards zu ASM Adressierungen, Syntax und Mnemonics [OT aus 'Assembler Tricks']
Schon wieder ein neues Topic? Ich bin ja artig und versuche den Regeln zu folgen

Quote from atomcode

Ich behaupte nicht, dass die blöd sind,

Ich habe auch nicht gesagt, DU würdest behaupten die seien blöd.

Quote from atomcode

Dito "sorry", aber zu glauben, in dieser Analogie wäre es tatsächlich ernst gemeint, die würden da noch mit dem 6502 hantieren, und es wäre jetzt wirklich wegen des Befehls verloren gegangen, finde ich etwas albern,

Gerade in der Raumfahrt ist es aus verschiedenen Gründen keineswegs völlig unüblich, vermeintlich "alte" Prozessoren einzusetzen. Das war nicht direkt der abwegige Teil deiner Analogie, und eben deswegen mit ein Grund dafür, deine Motivation für den Einsatz derselben undurchrschaubar zu machen. Es war nicht erkennbar ob du wörtlich meinst was du sagtest. Ich fürchte, das musst du jetzt mal einfach so glauben.

Quote from atomcode

umal das jeder bei Wiki nachlesen kann, wie es war, und da steht dann auch, dass der Hintergrund eben wohl recht trivial ist:

Der deutsche Wikipedia-Eintrag liefert nur eine noch grobere Vereinfachung als der englische es schon tut. Auf der Talk-Seite des englischen kann man in der Diskussion um Detailfragen Ansätze von der tatsächlichen Komplexität der Vorgänge erahnen (sehr knapp gesagt: es war durchaus bekannt dass unterschiedliche Einheiten zum Einsatz kommen, aber ein schlecht dokumentiertes und unvorsichtiges Update hat die Konvertierung ausgehebelt, und mangelhafte Prüfung hat weder das abgefangen, noch die entstehende Bahnabweichung). Dieser Artikel zum Thema von Jim Oberg ist z.B. eine wesentlich bessere Einstiegszusammenfassung zur Frage, was bei MCO alles schief gelaufen ist: https://spectrum.ieee.org/aero…ars-probe-went-off-course

@zrs1>"der NASA Vergleich ist wirklich hanebüchen."
Ich hatte aber lang und breit erklärt, inwiefern das nicht der Fall ist. In vielen Medien war deswegen sogar von einer Art "Schülerfehler" die Rede. Es ist vom Prinzip her dasselbe: Probleme durch mangelnde Einigkeit. Was gibt es daran nicht zu verstehen? Da kann man drumherum labern wie man will,; das ändert es nicht. Wenn hier was "um jeden Preis" geschieht, dann die akribische Zerlegung dieses einen Falls, nur um ihn als etwas völlig anderes dastehen zu lassen, und das, obwohl ihr längst genau wisst, was ich meine und worauf es ankommt; hab's ja nun wohl zu genüge erläutert. Ich hatte auch andere Totschlag-Beispiele genannt mit der Firma, der Uni, etc., aber ihr betreibt lieber bzgl. des NASA-Beispiels Haarspalterei.

>"So etwas zeigt in meinen Augen nur den Versuch, um jeden Preis recht zu haben und seine Sichtweise durchzudrücken."
Sehe ich eben genau umgekehrt. Ihr seid in der eindeutigen Minderheit und stützt euch auf ein Manual von 1976, das ich mir eben kopfschüttelnd selbst angesehen hatte. Später mehr. Im Script zum 65x02 der FH Köln, in dem es keine "Akkumulatoradressierung" gibt, steht auf Seite 6:

3.5. Hinweis zum 65X02
Der Prozessor 65X02 hat die Besonderheit, dass man die Shift-Befehle auch direkt im Speicher anwenden kann, ohne die Werte vorher in den Akku oder ein Register zu laden.

Es wird also genau andersherum gesehen, als ihr es beschreibt: Nicht die vermeintliche Akkumulatoradressierung ist die Besonderheit. Genauso wenig wie man von einer "Indexregisteradressierung" spricht.

>"und beide Schreibweisen führen, wenn vom Assembler unterstützt, zum genau gleichen Opcode"
Das tut es bei mir im Kopf aber schon nicht, wenn doch die eigentliche Konvention die ist, dass ein Opcode regelmäßig aus 3 Zeichen besteht und dahinter ein Operand, der die Daten für den Opcode bzw. für die CPU darstellt bzw. bereithält. Der Akku ist aber kein Datum und hat folglich da nichts verloren. 8086-Assembler hat ganz andere Konventionen, wo das wiederum normal ist. So hätte man es auch machen können, aber dann auch bitte eben in diese Richtung konsequent, also mit "INC X" etc., aber eben nicht mal so und mal so.

>"Du möchtest hier vielleicht diesen Fall mit dem Label "A" konstruieren, nur, ein Assembler, der die offizielle Schreibweise verlangt oder auch nur erlaubt, und gleichzeitig ein Label mit dem Namen "A", wäre ganz einfach kaputt. Wenn ein einzelnes "A" Teil der Sprache ist, ist es ein reserviertes Schlüsselwort und damit als benutzerdefinierter Bezeichner ausgeschlossen."
Sicherlich ist das problemlos machbar, aber, wie eben erklärt, halte ich genau das für viel fehlerträchtiger als -- den realen Bytes entsprechend -- nur den Opcode hinzuschreiben. Wer einen Operanden vergisst, ist selbst schuld, und das kann einem auch bei anderen Befehlen, zu denen es keinen implizierten gibt, passieren.

Es geht mir aber nicht darum, ob jemand für sich allein mit seiner Lieblingsschreibweise einen Fehler machen könnte, denn das wird aufgrund von Gewohnheit und Übung wohl kaum passieren. Ich sagte ja, dass ich mit der implizierten Schreibweise noch nie ein Problem hatte -- und ich lasse mir da auch keines andichten. Wahrscheinlich ist das bei den wenigen, die mit A-Adressierung schreiben, auch so. Aber wenn man, wie im Thread "Assembler Tricks" oder vllt. irgendwo im Entwicklungsteam, das mal so und mal so sieht, ist es für jeden fehlerträchtig. Wenn ich im Action-Replay-Monitor nach Fehlern oder einem bestimmten Code suche, lasse ich das meistens mit der bekannten Scroll-Geschwindigkeit durchscrollen. Das funktioniert nur, wenn die Mnemonik so richtig tief ins Hirn gebrannt ist. Würde da jetzt plötzlich hinter den implizierten Schiebebefehlen ein vermeintlicher Operand stehen, würde mich das extrem stören, und deswegen bin ich froh, dass das bislang bei keiner mir untergekommen Software und in keinem Buch so war.

Nun zu den MCS 6500 Specs vom Januar 1976.

>"Ich bin ja ebenfalls der Meinung, dass MOS bei der Definition der Assembler-Sprache an dieser Stelle inkonsistenten Mist gebaut hat."
Eine ausdrückliche Definition finde ich gar nicht in dem Manual. Es wird viel in symbolischer Schreibweise gearbeitet, mal so und mal so. Das ist für mich keine Definition. Es wird bei der Darstellung der verschiedenen Adressierungsarten noch nicht einmal zwischen ZP und Absolut unterschieden. In Anbetracht der Tatsache, dass sie die Mnemonik im Beispiel im erklärenden Teil zuvor selbst noch anders geschrieben hatten, wirkt das ganze einschließlich der Tabelle unten auf mich 1. noch unentschlossen und 2. eher symbolisch oder als Vorschlag, aber keineswegs absolut verbindlich für die endgültige Schreibweise. Offenbar war ich nicht der einzige, der das so sah.

@Bit Shifter
>"Wenn die Adressierungsart Accumulator gewählt wird, MUSS deshalb "ASL A" geschrieben werden."
Das steht nirgends so. S.o.

>"Es git zwar Assembler, die den Code "ASL" ohne Operanden akzeptieren und ohne Fehlermeldung den Code für "ASL A" erzeugen, .."
Was soll das: "Es gibt zwar Assembler, .."? Als wenn das eine Ausnahme wäre, und dabei weiß jeder, dass es umgekehrt ist. So viel zum Thema "um jeden Preis recht haben und um seine Sichtweise durchzudrücken". Ich habe seit Hypra-Ass noch nie was anderes gesehen. Das war 1985, also nur 9 Jahre später, wo es den C64 gerade mal 2 Jahre gab. Jetzt sind es geschlagene 42 Jahre später, und in all der Zeit haben es Millionen Leute anders gelernt, sodass die gängige Schreibweise zum Industriestandard wurde! https://de.wikipedia.org/wiki/Industriestandard

>".., dies verletzt allerdings den 6502 Standard."
Ach ja? Dann verletzt MOS Tech. ihn selbst in Kapitel 10, wo für "ASL" in einem Beispiel "ASLA" als eindeutig zusammenhängender Mnemonik und eben nicht als "ASL A" mit imaginärem Operand geschrieben wird. Aber ich bin ganz sicher, dafür gibt es "um jeden Preis" eine Erklärung.

. . . Bild links: Wie man bei MOS Tech. selbst noch nicht wusste, wie man es haben wollte.

Es sollte jedenfalls niemand mehr studieren gehen. Forum sollte reichen.

@ZeroZero >"Vielleicht geht das ja gar nicht"

Gehen täte das sicherlich schon in PHP. Es müsste sich nur jemand finden, der das macht. Allerdings habe ich noch nicht mal hier irgendwo eine Auflistung der verbreitetsten Assembler gefunden, um dafür Konvertierungsregeln zu ermitteln.
Für mich wäre es allerdings wichtiger, meine beiden Projekte weiter zu stricken, sonst wird das ja nie was. Meine eigenen Quellcodes muss ich nun von Hand ins ACME-Format umschreiben, und dann geht's weiter. Spaß macht's mehr denn je.

Quote from atomcode

@ZeroZero >"Vielleicht geht das ja gar nicht"

Gehen täte das sicherlich schon in PHP. Es müsste sich nur jemand finden, der das macht. Allerdings habe ich noch nicht mal hier irgendwo eine Auflistung der verbreitetsten Assembler gefunden, um dafür Konvertierungsregeln zu ermitteln.
Für mich wäre es allerdings wichtiger, meine beiden Projekte weiter zu stricken, sonst wird das ja nie was. Meine eigenen Quellcodes muss ich nun von Hand ins ACME-Format umschreiben, und dann geht's weiter. Spaß macht's mehr denn je.

Danke für den Zuspruch! Auch ich würde stets dem Industriestandard folgen, aber evtl. einen Pseudo-OP zufügen, der abweichend meinen geliebten 6502 statt des standardisierten 65X02 generieren kann, wenn es einzelne Verbraucher glücklich macht, vielleicht in der Form "* 6502 ASL" akzeptiert, also JEDEM Assembler die Ausnahmegenerirung durch Plug-In ODER Macro-Code ermöglicht. Mehr wollte ich ja gar nicht.

Danke nochmals für Deine Unterstützung, dass ich kein Vollnerd bin

@zrs1 >"Es ist und bleibt blühender Unsinn, weil es kein realistisches Szenario gibt, in dem es durch asl a vs. asl für den gleichen Opcode fehlerhaften Code geben kann."
Ja, weil ja auch bei NASA und co. alles automatisch läuft und sich nicht etwa Fehler durch unterschiedliches Verständnis des Geschriebenen einschleichen können, nicht wahr. Genauso eben beim Lesen und vor allem beim Arbeiten mit Assembler. Ein Kopieren des Codes erzeugt bei mir bereits direkt Fehler. So what? Man muss es erst alles korrigieren, ansonsten "geht die Sonde verloren". Scheint sehr schwierig sein, zu verstehen. Und vor allem ist es auch viel einfacher, immerzu auf diesem Beispiel herumzureiten, anstatt auf meine detaillierten Beschreibungen und parallelen Beispiele des eigentlichen Problems einzugehen, bspw. dass es eben keine Firma zulassen würde, dass jeder seinen eigenen Standard mitbringt.

>"Trommelwirbel, Applaus Wir haben doch wirklich ein fehlendes Leerzeichen entdeckt."
Und da ist sie auch schon, die angekündigte Um-jeden-Preis-Erklärung. Da haben die Ingenieure doch glatt in ihrer ach so verbindlichen Dokumentation gleich beim ersten Auftreten des ASL-Befehls zuuuuufällig und ausgerechnet nur bei diesem Befehl schon selbst einen Fehler gemacht, und das, wo doch diese Schreibweise so gar nicht fehlerträchtig ist. Merkwürdig, dass ich bereits an den Schwarzen Ritter aus Monty Python denken muss.

>"Gnihihi .. wenn wir jetzt im Angeber-Modus sind"
Ernsthaft? Da war weder was Witziges noch was Angeberisches. Da müsste ich @syshack im Nachhinein mit der Kindergarten-Aussage glatt noch Recht geben. Allerdings lege ich Wert darauf, sachlich zu bleiben.

Es ging um den Industriestandard, wie es am verbreitetsten gelehrt und genutzt wird und an keiner Stelle um mich! Auch in Dortmund an der FH wurde es nicht anders gelehrt (laut Bekanntem), und ich kann gern noch mehr abgrasen. Muss ich aber gar nicht, denn wäre es anders gelehrt worden, hätte es sich auch sicherlich anders durchgesetzt. Wenn Ihr paar Leute trotzdem meint, das wäre falsch, und es sei richtig, wie Ihr es auffasst ("verletzt den 6502 Standard"), dann ist meine Schlussfolgerung daraus, dass am besten Ihr selbst zu Haus die Vorlesungen für eure Kinder/Enkelkinder haltet, weil die das ja sonst nachher glatt noch so machen wie die breite Masse und sich damit womöglich in einer Firma integrieren können. Wie oft muss ich das eigtl. noch wiederholen, damit das überkommt? Mit mir persönlich hat das absolut nichts zu tun. "Verzweifeln, Recht haben wollen, Angeben, etc." .. Wenn man Argumente hat, muss man nicht persönlich werden; wenn. Die Energie sollte man sich lieber sparen, um auch auf unbequeme Gegenargumente einzugehen. Bspw. kein Pieps zum Tinkiwinki-Argument bzgl. des Pochens auf offizielle Standards. Warum, ist mir völlig klar. Demnach muss ich also davon ausgehen, dass hier jeder glaubt, der C64 hätte 64000 Bytes Speicher? Ich bin mir sicher, dass der absolute Löwenanteil hier im Forum noch mit den Einheiten arbeitet, die sich etabliert haben und eben nicht, was Offizieller Standard sein soll. Genauso sollten wir es also auch mit der Assembler-Mnemonik handhaben.

--//--

Zu der Plug-in-Sache später nochmal. Sollte nichts allzu Kompliziertes sein, dachte ich. Hatte da mehr an ein Import-Plug-in mit Konvertierung gedacht, nicht als Eingabe-Plug-in, obwohl letzteres dann ja nur noch ein kleiner Schritt wäre.
Muss nun erst wat tun.

@zrs1 "Lagerdenken" .. Ein Youtube-Kampfbegriff ohne Bedeutung.
Ihr: Es sind mindestens zwei hier, die den einen Standpunkt der Diskussion vertreten, bzw. die es anders handhaben als die breite Masse.
Wir: Die anderen und Ich. Kein Lager-"Denken", sondern beobachtbare Realität, wobei gewisse Schnittmengen nicht explizit ausgeschlossen wurden.

>"Da kann ich jetzt aber nur noch lachen"
Ich weiß.