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

Es gibt 58 Antworten in diesem Thema, welches 16.960 mal aufgerufen wurde. Der letzte Beitrag (5. Mai 2018 um 17:23) ist von 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. :)

    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.

    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.

  • 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" :P
    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

    Code
    jmp *


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

    Code
    bvc *


    nutzt. :whistling:

    salute

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

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

    Wobei Dein Beitrag weiter oben auch nicht besonders hilfreich ist, IMHO. Ein Plugin fuer was? Wie steht dies im Zusammenhang mit ASM Tricks und Optimierungen?

    ___________________________________________________________
    Meine Kreationen: 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. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

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

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

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

  • Bitte melde dich an, um diesen Link zu sehen. der NASA Vergleich ist wirklich hanebĂŒchen. So etwas zeigt in meinen Augen nur den Versuch, um jeden Preis recht zu haben und seine Sichtweise durchzudrĂŒcken. Wie du ja schon selbst feststellst sind die Opcodes relevant, und beide Schreibweisen fĂŒhren, wenn vom Assembler unterstĂŒtzt, zum genau gleichen Opcode. 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.

    Ich bin ja ebenfalls der Meinung, dass MOS bei der Definition der Assembler-Sprache an dieser Stelle inkonsistenten Mist gebaut hat. Diese Inkonsistenz behebt man aber nicht, indem man das "A" einfach weglĂ€sst, man ersetzt sie dann nur durch eine andere. Falls das nicht ganz ankam: Es ist schlechtes Sprachdesign, wenn ein Kommando einen optionalen Parameter hat, einfach weil man damit eine weitere Möglichkeit hat, Bugs einzubauen, die der Parser nicht erkennen kann. Eine in sich konsistente Definition der Assemblersprache hĂ€tte also statt asl a einfach einen eigenen Mnemonic vorgesehen, wie beispielsweise sla. Nun ist es aber wie es ist, und ich persönlich bevorzuge die offizielle Schreibweise, wĂŒrde aber doch sehr dafĂŒr plĂ€dieren, jeden das nutzen zu lassen, was er lieber mag.

    Zum Thema verschieben: Ja bitte. Hier aber mit "Kindergarten" um die Ecke zu kommen ist in der Tat fehl am Platz. Ich finde es zwar auch albern, mit welcher Vehemenz hier teilweise von beiden Seiten versucht wird, die einzige Wahrheit fĂŒr sich zu beanspruchen -- nichtsdestotrotz ist die Diskussion insofern interessant, als sie mal die Fakten (welche Opcodes, Bitmuster gibt es, was wurde offiziell definiert, ...) zusammentrĂ€gt. Das ist absolut on topic im Bereich Programmieren/Assembler, aber natĂŒrlich off topic in speziell diesem Thread. Letzteres wird im Format "Webforum" immer wieder passieren -- Diskussionen verzweigen eben gerne mal und wenn man versucht, sie als eine gerade Linie abzubilden (und nicht, wie z.B. im alten Usenet, als Baum), dann hat man das Thema hin und wieder. Da darf dann jemand mit ausreichenden Rechten so freundlich sein, etwas Ordnung mit Querverweisen reinzubringen, vielen Dank :)

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

    Es kann ja nicht die Erwartungshaltung sein, dass die Mods dann immer alles schön auseinandernehmen und auslagern, weil man selbst keine Disziplin versucht aufzubringen, Themen etwas abgesteckt zu diskutieren.
    Mit der Vermischung der Themen innnerhalb einzelnen Posting ist es auch nicht immer ganz einfach, den Thread auseinanderzunehmen und ist manchmal auch mit nicht zu unterschÀtzendem Aufwand verbunden.


    Bitte melde dich an, um diesen Link zu sehen. >"Soll der Thread gleich in Laberecke-->Kindergartenecke?"
    Diese Provokation halte ich jetzt eher fĂŒr emotional.

    Das war auch so gedacht. Diese Diskussion ob jetzt ein A oder B oder C oder nichts hinter einem StĂŒck Text geschrieben wird, driftete ins religiöse "Meine Schreibweise ist die einzige Richtige", obwohl das ganze reine Definitionssache ist.

    Auch die Reaktion auf Bitte melde dich an, um diesen Link zu sehen.'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.

    Ich habe nichts gegen Standards und Definitionen, ich definiere sie selbst tÀglich in meiner Jobrolle. Aber darum geht es im Original Posting und Thread-Titel ja nicht.
    Wie wird der Gedanken Link zwischen "Coding Standard" und Plugin hier hergestellt? Das ist etwas was du jetzt assoziierst, ich habe das nicht so gesehen, vor allem auch wegen dem Hintergrund der C64 Studio PlugIns, siehe unten, aber auch wegen der Thread-Thematik von optimierten ASM Code.

    ZeroZero und ich haben im Bitte melde dich an, um diesen Link zu sehen. Thread durchaus die PlugIn Idee (aber thematisch fĂŒr was Anderes) diskutiert und dort macht sie im Kontext des Threads durchaus Sinn.
    Aber in diesem Thread muss ich nochmals Fragen, um was fĂŒr ein PlugIn oder System es sich handeln soll? Das geht aus dem kurzen Posting nicht wirklich hervor (fĂŒr mich).
    Geht es um ein PlugIn fĂŒr C64 Studio?
    Was soll das PlugIn machen? Code einfĂŒgen? Bestehenden Code nach den Tipps hier optimieren oder was ist der Gedanke dahinter? Das ist mir hier nicht ganz klar.


    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?

    ___________________________________________________________
    Meine Kreationen: 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. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • 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 Bitte melde dich an, um diesen Link zu sehen.
    Schon wieder ein neues Topic? Ich bin ja artig und versuche den Regeln zu folgen :)

  • Ich behaupte nicht, dass die blöd sind,

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

    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.

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

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

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

    >".., 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.

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

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

  • Gehen tĂ€te das sicherlich schon in PHP. Es mĂŒsste sich nur jemand finden, der das macht.

    Ich habe immer noch nichts Konkretes gelesen, was Euch denn so vorschwebt mit diesem "PlugIn" und was es tut soll:

    • Intellisense/Incremental Typing Eingabe bei den ĂŒblichen Editoren und IDEs wie Notepad++, C64 Studio, CBM Studio, Visual Studio/Code & co.
      Wenn jemand ein ASM Projekt eröffnet und anfĂ€ngt AS einzugeben, werden z.B. alle ASL Varianten angezeigt, die man per Cursortasten auswĂ€hlen und mit ENTER in den Editor ĂŒbernehmen kann? (So kenne ich es vom Visual Studio und Visual Code)
    • Ein systemweiter Tasten-Shortcut, der ein GUI Tool aufpoppt und man daraus in einer Liste die Mnemonics und Adressierungsarten auswĂ€hlen und ins Clipboard oder in jedes beliebiges Textfeld (z.B. auch hier im Browser) ĂŒbernimmt?
    • Ein spezielles GUI Tool, wo man die Adressierungsarten nachschlagen und eine konkrete Auswahl ĂŒbernehmen kann?

    Das Problem mit "nur" ist ---> Damit ist es also wie die restlichen gefĂŒhlten 95% aller Ideen im Forum: Ideenlieferanten gibt es viele, nur Umsetzer und konkrete Projektspezifikationen gibt es zu wenige.
    Solange nichts Fassbares spezifiziert wird, macht es null Sinn von einer Programmiersprache wie PHP zu sprechen. Offensichtlich hast Du aber, wenn Du schon PHP erwÀhnst, schon konkretere Vorstellungen wie sowas aussehen soll.
    Kannst Du uns da ein bisschen Deine Gedanken ausplaudern?


    Was ich mir vorstellen könnte, um das PlugIn Thema von ZeroZero aus dem anderen Thread wieder hervorzubringen, dass man ein Intellisense-PlugIn fĂŒr das C64 Studio schreiben könnte, welches dann wĂ€hrend man tippt eben diese Schreibweise der Adressierungsarten vorschlĂ€gt. Das ist aber mit dem heutigen Editor vermutlich nicht ganz banal.


    Eine Webseite / Wiki mit allen Adressierungsarten und ErklĂ€rungen sehe ich eher im plastischen (=realisierbaren) Bereich, zumindest als ersten Schritt. Da mĂŒsste man auch nichts programmieren, sondern auf bestehende CMS zurĂŒckgreifen.
    Das wÀre auch im Sinne aller Lösungen, weil das auch als Referenz dienen kann.

    ___________________________________________________________
    Meine Kreationen: 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. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

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

  • Ich hatte aber lang und breit erklĂ€rt, inwiefern das nicht der Fall ist

    Nö. Du hast nur verzweifelt gerungen. 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.

    Wenn man unbedingt etwas konstruieren will, sind (sehr unwahrscheinliche) Fehler nur mit einem Assembler möglich, der asl erwartet. Da wĂ€re es dann immer noch nötig, dass jemand ein Label "a" definiert, wozu man eigentlich nichts weiter sagen muss. Erwartet der Assembler dagegen asl a fĂŒhrt sowohl der Versuch, ein Label "a" zu definieren, als auch eine Schreibweise mit vergessenem Operanden zu einem Fehler beim assemblieren.

    Dann verletzt MOS Tech. ihn selbst in Kapitel 10

    Trommelwirbel, Applaus :D Wir haben doch wirklich ein fehlendes Leerzeichen entdeckt.

    Script zum 65x02 der FH Köln [...] Es sollte jedenfalls niemand mehr studieren gehen. Forum sollte reichen

    Gnihihi .. wenn wir jetzt im Angeber-Modus sind -- also ich habe so ein Dipl.Inform. Dingens ohne irgendn FH Zusatz ... und n "best paper award". War auch schon manchmal ein wenig verwundert ĂŒber so manche FH Materialien ... und bei DHs sieht es noch schlimmer aus. Lassen wir das besser ;)

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

  • Allerdings lege ich Wert darauf, sachlich zu bleiben.

    Da kann ich jetzt aber nur noch lachen ;) Der Rest dieser "Diskussion" steht fĂŒr sich -- inklusive Lagerdenken mit "ihr" und "wir" -- wird mir entschieden zu dĂ€mlich.

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