Hallo Besucher, der Thread wurde 1,8k mal aufgerufen und enthält 6 Antworten

letzter Beitrag von BlackJack am

(M)Ein Template für C64 ASM Files für Anfänger - Bitte kritisieren

  • Hallo alle nochmal


    Ich hoffe ich störe nicht zusehr wenn ich schon wieder einen neuen
    Thread aufmache...
    Aber der andere Thread:
    Konstanten, Variablen, Lables & Symbole, was für ein Durcheinander! :-O
    ist ziemlich Informativ und auch ein anderesThema. Es wäre schade
    den zusehr mit neuen Themen zu überladen / derailen...


    Ich hab mir jetzt, da ich weiss dass es hier ein paar echt gute und
    erfahrene Programmierer gibt, gedacht, ich veröffentliche mein
    zusammengewursteltes Template für C64 Assembly Source Code
    doch einmal.
    Schlimmstenfalls kann ich ja nur ausgelacht oder ausgepeitscht werden...
    ;)<X:schande:


    Zur Erklärung:
    Ich programiere nur sporadisch und vergesse dann manchmal dazwischen
    eine Menge über eine Sprache. Deswegen mach ich mir für verschiedene
    Programiersprachen (zumindest bei C und C++ hab ich das angefangen)
    ein Template für Source Code. Der Sinn davon ist einfach dass man, wenn
    man das Template benutzt, viel schneller wieder in den Code einer Sprache
    reinkommt und weniger Fehler macht indem man Variblen am falschen Ort
    einführt, deklariert, Files am falschen Ort included, usw.
    Kann ja alles passieren und das erschwert den Einstieg nach Abwesenheit
    immer *enorm* und ich hasse das.
    Natürlich könnte es auch kontroproduktiv sein und Gefahren bergen, aber
    das bin ich mir im Moment (noch) nicht bewusst, deswegen gefällt
    mir die Idee bis jetzt noch...


    Aber wie gesagt, da es hier sehr erfahrene Programmierer gibt, nimmt
    es mich zu sehr wunder was die davon halten, als ich mich vor der
    Blamage schäme dass das vielleicht ein völliger Mist ist.
    Also: Was haltet Ihr von der Idee eines Template wie dem hier für
    C64 Assembly Source Code (für Anfänger)?
    Bitte kritisieren!!


    Die Idee ist hier ganz bewusst dass ich Eure (möglichst sachliche)
    Kritik will! Zudem wimmelt es bestimmt von Fehlern - jeglicher
    Art, gedanklich, programmtechnisch, usw. Also bitte kritisieren!
    Die paar wenigen Codezeilen die es darin hat, sind nur als Beispiele
    gedacht und auskommentiert. Einfach für das Verständnis, damit man
    eben schneller und leichter reinkommt.


    Hier das Template: Bitte kritisieren! X/:search:



    LG,
    Markie

  • Hallo, Markie.


    Ich hab' mal etwas schärfer darübergeschaut.


    Im wesentlich hast Du jetzt erstmal alles in einem Source-File zusammengetragen, was Du über den Aufbau eines gängigen Programms mit BASIC-Stub zusammengetragen hast. Als Referenz ist sowas immer brauchbar. :)


    In der Praxis wirst Du aber die Kommentare weitgehend zusammenkürzen müssen. Ich denke hier ist schon der Punkt erreicht, wo es schwierig wird zwischen all der Kommentierung überhaupt noch den eigentlichen Quelltext wieder zu finden.


    Ein Header mit Projekt-Name, dann eine Liste mit Datum Ersterstellung, Datum Änderung (evtl. mehrere), Datum letzte Änderung - jeweils mit Autor und Grund - ist immer eine gute Idee.


    Vor allen Programmteilen, die als Unterroutine angesprungen werden können, ist eine kurze Kommentierung mit Funktion, verwendete Resourcen (Register, etc.) ebenfalls Pflicht.


    Bei der Vergabe von Label-Namen verwende ich seit geraumer Zeit folgendes Schema: der Einsprungsprung einer Unterroutine wird z.B. ".Clear" genannt (je nach Assembler entfällt z.B. der anfängliche Punkt), weitere Ziele *innerhalb* der Unterroutine werden mit angehängtem Underscore und einer zweistelligen Zahl durchgezählt, also ".Clear_00", ".Clear_01" bis ".Clear_99" - die 100 Ziele reichen im Regelfall aus. Das funktioniert auch mit einem Assembler ohne lokale Labels und vermeidet generische Labels mit ".loop" oder ".skip" (<- das kann nämlich eine Menge Ärger machen, wenn man zwei Source-Files kombiniert!)


    zu guter Letzt dann noch das:

    Zitat von Markie
    Code
    1. ;-----------------------------------------------------------------------
    2. ;-- Declare my own variables placed by the compiler.
    3. ;-- This MUST be done at the end of the program, otherwise it seems
    4. ;-- that you screw up your program / the program pointer or something!
    5. ;-----------------------------------------------------------------------

    (Zeilen 152 bis 156): das kann ich nicht wirklich nachvollziehen. Es ist ohne weiteres möglich, veränderliche Daten innerhalb eines Programms, also z.B. vor und zwischen Unterroutinen, abzulegen. Da besteht kein Zwang, die ans Ende zu setzen.


    ...


    Evtl. wäre es jetzt an der Stelle sinnvoll, ein kleines prototypisches Programm zu schreiben, welches eben einen BASIC-Stub enthält und das gleiche macht wie das "Up-Up-and-Away" im Bedienungshandbuch. :)



    Edit: noch was. Ein Übersetzer eines Quellcodes mit Maschinenbefehlen und Labels wird für gewöhnlich "(Symbolischer) Assembler" genannt. Für einen *Compiler* muß es sich dann schon um eine höhere Sprache handeln, die da aus dem Quellcode übersetzt wird.

  • Was haltet Ihr von der Idee eines Template wie dem hier für
    C64 Assembly Source Code (für Anfänger)?
    Bitte kritisieren!!

    Da stimme ich Mike zu: Das sind eigentlich schon zu viele Kommentarzeilen, um noch übersichtlich zu sein.
    Dank Syntax-Highlighting sind heute auch diese Rahmen aus Sternchen überholt - große Kommentarblöcke fallen schon durch ihre Farbe auf, da verschwenden Umrandungen nur Platz auf dem Bildschirm. Aber gut, das sind persönliche Präferenzen.

    C
    1. ;** These Symbols need to be resolved in the first compiler pass. **
    2. [...]
    3. ;** These Symbols are resolved in the second compiler pass. **

    Andere Assembler sind da evtl. restriktiver, aber ACME macht immer genau so viele Passes wie nötig: Manchmal reicht schon einer (wenn es keine Vorwärtsreferenzen gibt), manchmal sind auch vier oder mehr nötig (wenn man fiese Makro-Magic verwendet o.ä., das ist aber nichts für Anfänger).
    Anstatt diese Sätze jetzt zu "korrigieren", würde ich sie aber einfach weglassen, denn sie sind für die Syntax unerheblich.

    C
    1. ; SCREEN_CHAR = 52224

    Im Ernstfall würde das ca. jeder in Hex angeben. ;)

    C
    1. ;-- Next BASIC line starts at: 2049 + 27 = 2076
    2. ;-- $2076 = $081C in lo/hi = $1C, $08
    3. ;-- BASIC line number 10 in lo/hi = $000a = $0a, $00

    Das ist Verschwendung wertvoller Lebenszeit. Der Assembler ist Dein Freund und will Dir helfen, Du musst ihn nur lassen. Statt Basic-Zeilen aus Bytes zusammenzustoppeln und alle Berechnungen selbst zu machen (und in den Kommentaren zu beschreiben), lass das das Werkzeug machen:

    Das passt sich automatisch an längere REM-Texte an.

    C
    1. !text "*** PROJECT NAME ***" ; !text translates to PETSCII codes

    Für eine Konvertierung zu PetSCII muss man entweder "!pet" benutzen oder vor "!text" mit "!ct pet" umschalten.

    C
    1. !byte $00, $00 ; end of BASIC line
    2. ;-- NULL, NULL instead of pointer to next BASIC
    3. ;-- line signifies end of BASIC program:
    4. !byte $00, ; end of BASIC program

    Der Kommentar ist richtig, die Nullen sind aber falsch verteilt (eine nach oben, zwei nach unten).

    C
    1. ;-- Declare my own variables placed by the compiler.
    2. ;-- This MUST be done at the end of the program, otherwise it seems
    3. ;-- that you screw up your program / the program pointer or something!

    Wie Mike bereits schrob: Du kannst Variablen anlegen, wo immer Du willst. Nur anspringen sollte man diese Bereiche natürlich nicht. Wenn da etwas nicht funktiniert hat, hast Du die Werte evtl. in eine Routine gelegt, statt zwischen Routinen.

  • Kleine Anregung: Ich würd noch irgendwo vermerken für welchen Assembler der Sourcecode geschrieben ist. Das ist zwar jetzt noch nicht so brisant, aber falls du irgendwann mal deine Werke mit der Welt teilen willst, muss die Welt dann nicht lange rumrätseln womit sich die Sourcen assemblieren lassen. :)

  • Meine persönliche Reihenfolge ist anders.
    -Macros,
    -Includes von Daten mit fester Adresse (Musik, Grafik...)
    -Basic-Zeile und ein erstes bisschen Code wie Kopierschleifen o.Ä. dazu.
    -Dann für größere Funktionsblöcke, z.B. Diskroutinen, Zeichenroutinen, Raster-IRQs...:
    [ -Variablen
    -Unterprogramme: Deren lokale Variablen, dann der Code dazu
    -Der eigentliche Code]
    Und zu guter Letzt die Hauptroutine, die all die anderen Sachen verwendet.


    So gibt es wenig Vorwärts-Referenzen, im besten Falle gar keine.

  • Hallo alle!


    Oh, wow, da kann ich gleich ne ganze Schubkarre voll Tipps
    und Hilfen / Korrekturen mit nach Hause nehmen!! :):thumbsup:
    Danke!! :)


    Mein Quellcode ist im original *etwas* übersichtlicher, weil ich
    auch viele Leerzeilen zwischen Abschnitten habe. Leider aber
    gibt es hier im Forum anscheinen keinen Modus um Quellcode
    vernüftig darzustellen. Entweder ist er dunkelrgrün auf dunkelblauem
    Hintergrund (Brainfuck), kaum lesbar, oder eben die Leerzeilen
    werden einfach rausgeschnitten... suuper... - oder gar beides.


    Aber Ihr habt mir viele gute Anregungen und Korrekturen
    gegeben! Danke! Jetzt muss ich die nur noch alle einbauen!! :-)



    Wenn man zuerst die Includes von Daten mit festen Adressen hat,
    verschiebt das dann nicht den Programmstart auf eine unbekannte
    Adresse? Ich mein kann es dann nicht sein, dass man gar nicht
    weiss, welche Speicherzahl man für den Programm-Zähler angeben
    muss weil man ja dann nicht weiss, wo der erste Befehl / Instrucion
    hinkommt nach all den Daten?
    Blöde Frage wohl... ;-)


    LG,
    Markie