Hallo Besucher, der Thread wurde 5,7k mal aufgerufen und enthält 26 Antworten

letzter Beitrag von the_cky am

Welcher Assembler darf es denn sein?

    Moin!
    Ich hoffe, das Thema wurde nicht schon zu Tode diskutiert - zumindest habe ich auf die Schnelle nichts gefunden.


    Es gibt ja mittlerweile eine große Auswahl an Cross Assemblern. Gepflegt werden u.a. diese hier


    Stand Alone:

    • ACME
    • c64tass
    • KickAss


    IDEs

    • CBM prg Studio
    • C64 Sudio (hat das eigentlich seinen eigenen Assembler?)


    Mit KickAss läuft es bei mir eigentlich ganz gut, aber ich habe die Sorge, dass ich durch die Macro-Syntax mir jetzt was völlig verquertes angewöhne, dass ich später nie wieder loswerde. Auch viele Beispiele in der CodeBase64 haben die Acme Syntax, die im c64-wiki sowieso.


    Lohnt es sich, umzusteigen? Oder doch lieber 64tass? So einen richtigen Vergleich zwischen den ganzen Assemblern habe ich leider nicht gefunden. Aus dem Bauch herraus würde ich sagen, dass Acme hier im Forum der Platzhirsch ist :)

    @enthusi Wow, der XA Asm wird ja schon seit '89 entwickelt. 8o


    @BR0TK4$T3N Das ist gewissermaßen auch der Grund, warum ich den KickAss mittlerweile etwas skeptisch betrachte. Der kann so viel Macro/Pseudocommand Gedöhns, dass mir schwindelig wird.


    Ich habe derweil auch gemerkt, dass die beiden IDEs mittlerweile mit HighDPI Skalierung umkönnen - das war letztes Jahr noch nicht so, cool!

    Meine persönliche Empfehlung:
    1.) Nicht nur für den Anfänger, aber für den besonders sind ACME bzw. das C64Studio die erste Wahl. Beide Assembler verwenden die gleiche Syntax und sind nahezu 100% kompatibel zueinander. Mit dem C64Studio hast Du außerdem noch eine schöne IDE mit dabei. Die verwendete Syntax findet sich zudem häufig auch in diversen Quelltexten im Internet. Wie Du weißt, sind beide Entwickler (Mac Bacon und Endurion) aktive Mitglieder im Forum, entwickeln ihre Assembler beständig weiter und berücksichtigen dabei auch Anregungen der Benutzer.
    2.) Solltest Du in Zukunft (bei sehr, sehr großen Projekten) mal in die Verlegenheit kommen, mit einem Linker arbeiten zu müssen, kannst Du dann getrost immer noch auf xa65 und ca65 zurückgreifen, doch meiner Erfahrung nach braucht man heutzutage eigentlich keinen Linker mehr, sondern nur einen Assembler, der einem alle Programmodule in einem Rutsch assembliert.
    3.) Was Macros anbelangt, würde ich mich gerne meinen Vorrednern (auch aus anderen Threads) anschließen und darauf hinweisen, daß die Verwendung von Macros selten Sinn macht, dafür aber oft die Lesbarkeit des Codes oder den erzeugten Code selbst verschlechtert. Es gibt wirklich sehr, sehr wenige Fälle, in denen man Macros gewinnbringend verwenden kann. Als Anfänger wäre es aber besser, darauf zu verzichten, da sie den eigentlichen Code verschleiern und verhindern, daß man ein Gefühl für ein gutes Assemblerprogramm inklusive Optimierungen entwickelt.

    Okay, dann schaue ich mir mal Acme bzw das C64 Studio mal genauer an. Ich muss als Anfänger gestehen, dass der Debugger im C64 Studio schon sehr cool und hilfreich ist. Bis gestern habe ich das alles zu Fuß im Vice gemacht.


    Auch die Outline und die Speicherbereiche sind wirklich beeindruckend komfortabel.


    Das Fontrendering im Texteditor des C64 Studios ist allerdings noch ausbaufähig ;)

    Ich steuere mal einen Vergleich Kickass vs ca65 bei, mit anderen Assemblern habe ich keine persönliche Erfahrung :)


    Kickass:

    • Implementierung in Java mit allen Vor- (läuft überall wo es eine Java VM gibt) und Nachteilen (entsprechend groß und Java VM muss erst installiert werden)
    • Assembliert direkt in ausführbaren Code, Platzierung im Speicher geschieht über simple Pseudo-Opcodes direkt im Source
    • Preprozessor-Syntax angelehnt an C, auch Kommentare sind (eher C64-Assembler untypisch) mit // oder /* .. */ zu markieren
    • Sehr mächtige Skriptsprache integriert, hat "bequeme" Möglichkeiten für viele Standardaufgaben (Bilder/Sound einbinden und sowas)

    ca65:

    • Implementierung in C, entsprechend schlank, muss aber für jede Zielplattform erstmal compiliert werden (binaries für Windows natürlich verfügbar)
    • Syntax ist (IMHO) "gewohnter", erlaubt exakt die Schreibweise aus der 6502 Doku (wie z.B. das etwas seltsame asl a), Kommentare mit ;
    • Assembliert in linkbaren Objektcode, der Linker (ld65) kann den Code dann anhand einer Konfiguration im Speicher platzieren
    • Eher einfacher Preprozessor, hat aber alles, was man für strukturierte Projekte braucht (bedingte Assemblierung, Makros, Scopes, "Prozeduren"...)


    Unterm Strich sind beides gute Assembler mit sehr unterschiedlichem Fokus. "Killerfeature" des Kickass ist wohl die Skriptsprache und die ganzen netten Helfer, die dabei sind -- hier hatte man wohl hauptsächlich Demo-Coding im Blick. Der ca65 dagegen wurde entwickelt um einen C-Compiler (cc65) zu unterstützen, ist daher besonders stark für große Projekte, die man modular aufbauen will (semantisch zusammengehöriger Code jeweils im gleichen File, der Linker übernimmt dann die Platzierung im RAM).


    Bei Kickass wird vermutlich in einer zukünftigen Version ein vernünftiger Support zum automatischen befüllen mehrerer Segmente, ähnlich wie bei ca65, nachgerüstet werden -- allerdings ohne separaten Linker. Trotzdem sollte damit dann auch das Management größerer modularer Projekte einfacher werden.

    Ich stand vor ein paar Jahren vor der gleichen Frage und meine Wahl fiel nach ausgiebigem Gebrauch beider letztlich auf ca65. Ich verrmisse zwar die Skripting-Möglichkeiten von KickAssembler manchmal, aber für mein (zugegebenerweise großes) Projekt war ein Linker einfach ein Riesenvorteil. Ich habe seitdem keinen einzigen Gedanken mehr an irgendwelche Speicheraddressen (außer der VIC-Bank und ein paar festen Puffern) verwendet, alles funktioniert einfach.


    Mit KickAssembler bin ich gelegentlich in zyklische Abhängigkeiten geraten, die sich nur hässlich lösen ließen (2 Assemblerschritte, nach dem ersten irgendwelche Labels parsen und dann geskripted in den zweiten Schritt füttern, oder womöglich Jumptables(!)). Außerdem gab es zu der Zeit ein paar Einschränkungen im KickAssembler, z.B. dass man .pseudopc Anweisungen nicht verschachteln konnte (toll, wenn man einen Schnelllader hat, den man am Anfang woanders hinschieben will, der aber wiederum Drive-Code enthält :cursing: ). Meiner Bitte, dass mal nachzuziehen wollte Slammer leider nicht nachkommen, weil er den Anwendungsfall unwichtig fand. Da kommt ein weiterer Nachteil von KickAssembler ins Spiel: leider ist er Closed Source und man kann selber nichts ändern.


    Rückblickend war es glaube ich die richtige Wahl, ich erzeuge meine Tabellen flugs in Octave oder einem Java-Programm, da lässt sich der Verzicht auf die zugegeben tollen Skriptingmöglichkeiten verschmerzen.


    Edit: ich konnte ca65 und ld65 problemlos unverändert für alle meine Plattformen (MacOS, Linux x86, Linux ARMv7) übersetzen.

    Etwas wenig beachtet ist der Ophis 6502 Crossassembler. Der hat eine gute Beschreibung auch für Programme in der C64 Umgebung.

    In der Zeitschrift für Assyriologie übersetzte H. Zimmern 1896 einen fast 3000 Jahre alten Text, der in den Ruinen der Bibliothek des Assurbanipal in Ninive gefunden wurde, aus der Keilschrift ins Deutsche. Auf dem Tontäfelchen hatte der Umanu (Weisheitsvermittler) Shaggil-kinam-ubib notiert:

    ,Schaust du hin, so sind die Menschen insgesamt blöde.‘

    Das fasst im Prinzip alles ganz gut zusammen.“

    @Claus aus meiner Sicht kann ich dir hier nur zustimmen, zumindest im Moment ist der ca65 für mich persönlich das bessere Tool, und ich verfolge da auch die gleiche Strategie: Was man bei Kickass mit dem integrierten Scripting lösen könnte baue ich mir für ca65 als externe code-generierende Tools. Der Vorteil des Linkers überwiegt gewaltig -- besonders hilfreich finde ich das auch bei der verwendung der ZP für "private Variablen" eines Moduls, ich muss mich eben nicht darum kümmern, welche konkreten Adressen verwendet werden, kann also alles mögliche an bestehenden Modulen ohne Source-Änderung einfach "zusammenlinken".


    Natürlich ist der ca65 Code wunderbar portierbar, Probleme hatte ich damit auch noch nicht. Ich habe jetzt einige Stunden darin "versenkt", einen FreeBSD Port zu bauen, weil das Build-System leider nicht so toll ist -- aber es geht.


    Allerdings kommt man beim Demo coden kaum um KickAssembler herum, weil den eben viele dafür einsetzen, wegen der hier hilfreichen Features -- ist ja auch nachvollziehbar. Deshalb hoffe ich, dass eine neuere Version endlich ein wenig mit ca65 mithalten kann was die Verwendung von Segmenten angeht :)

    Wegen dem Assembler-Wirrwarr habe ich meinen eignen Assembler nach C# portiert.
    Den hatte ich Mitte der 80iger mangels erschwinglicher Cross-Compiler in C geschrieben.
    Der Hauptgrund für die Portierung war, dass ich meine alten Assemblerprogramme weiter bearbeiten wollte. Und ausserdem noch einige Assemblerquellen aus dem Internet .
    Den eigenen Assembler kann ich flexibel an die meisten Quellen anpassen.


    Mit den Assemblern, die Hochsprachen nachahmen und z.B. geschweifte Klammern verwenden (C64Studio und ACME?) , habe ich so meine Probleme.
    Mit dieser Syntax kann ich mich nicht anfreunden. Da benutze ich dann doch lieber gleich CC65 - also richtiges C.


    Klar, das nutzt jetzt niemandem etwas. Aber das ist meine Lösung. :D

    Zitat von mrsid

    Irgendwo dazwischen liegt dann k2asm

    Interessant, den kannte ich noch gar nicht! Der sieht in der Tat so aus, als böte er alles was ca65 kann und noch mehr. Hmpf, zu spät zum umsteigen, vielleicht fürs nächste Projekt dann ^^ .

    Tut mir leid, wenn ich diesen Thread noch einmal hervor hole. Es würde mir gerade sehr helfen, wenn einer der Experten hier noch eine Pro/Contra Liste ca65 vs. ACME ergänzen könnte mit Schwerpunkt auf Entwicklung für den C64.


    Subjektiv scheine ich am häufigsten auf den ACME zu treffen, was ist ein "Pro" für diesen wäre, schon wegen der verfügbaren Code-Beispiele. Aber der Linker und potentiell auch der "passende" C-Compiler sind gute Argumente für die cc65 Tools. Was wären denn weitere Argumente? Gibt es bestimmte Arten von Projekten, die sich mit dem einen oder dem anderen besser umsetzen lassen? Wie sieht es mit Editor- oder gar IDE-Integration aus? Debugging? Spielt das OS der Entwicklungsmaschine eine Rolle?