Hello, Guest the thread was called7.3k times and contains 63 replays

last post from Mac Bacon at the

Neues ACME-Release

  • Hi!


    ACME hat jetzt die Versionsnummer 0.96.3, für den Link zum Source siehe meine Signatur.
    Die Änderungen sind:

    • Neuer Pseudo Opcode: "!hex" bzw. "!h" fügt Binärdaten ein. Im Gegensatz zu !by $1a, $3c, $5e, $70 ist !h 1a3c5e70 einfach sehr viel kürzer. Gedacht ist das Feature für externe Tools wie eigene Sourcecode-Generatoren; ursprünglich kam mir die Idee bei der Text-Compression-Compo.
    • Neuer Pseudo Opcode: !skip 17 macht das Gleiche wie * = * + 17, fängt dafür aber kein neues logisches Segment an. Das scheint erst mal nicht sonderlich nützlich zu sein, aber ein für die Zukunft geplantes Feature wird diesen Pseudo Opcode brauchen - und da er relativ einfach implementiert werden konnte, habe ich das gleich jetzt erledigt.
    • Unterstützung für "cheap locals": Neben den bisherigen lokalen Symbolen mit dem Präfix "." gibt es jetzt auch lokale Symbole mit dem Präfix "@". Der Unterschied ist, dass man den Gültigkeitsbereich nicht manuell per !zone abstecken muss: Die @-Labels gelten immer nur im Bereich zwischen den beiden globalen Labels davor und danach.
    • Neuer CLI Switch --fullstop: Damit wird der Präfix für Pseudo Opcodes von "!" zu "." geändert. Das ermöglicht das Assemblieren von Quelltexten anderer Assembler (wie z.B. TASS) mit deutlich weniger Konvertierungsarbeit. Natürlich funktionieren dann die lokalen Labels mit "." am Anfang nicht mehr richtig, aber solche sollten in den entsprechenden Sources ja eh nicht vorkommen.
    • Bugfix: Fehlerhafte mathematische Ausdrücke wie in lda #1)+1 haben in älteren Versionen nach der Fehlermeldung zu Abstürzen geführt. Vielen Dank an Bitbreaker für den Bugreport!
    • Neue Warnung: Zeropage-indirekte Adressierungsarten mit der Adresse $ff erzeugen eine Warnung, da das Highbyte des Pointers nicht von $0100, sondern von $00 geholt würde. Bei den 24-Bit-Pointern der 65816-CPU passiert das natürlich auch für $fe. Vielen Dank an Gerrit für den Vorschlag!

    Viel Spaß damit, und Probleme bitte sofort melden...

  • Neuer Pseudo Opcode: !skip 17 macht das Gleiche wie * = * + 17, fängt dafür aber kein neues logisches Segment an. Das scheint erst mal nicht sonderlich nützlich zu sein, aber ein für die Zukunft geplantes Feature wird diesen Pseudo Opcode brauchen - und da er relativ einfach implementiert werden konnte, habe ich das gleich jetzt erledigt.


    Klasse und vielen Dank dafür!


    Was ich aber noch vermisse ist ein Befehl, ähnlich dem obigen Zitat:


    Ich nenne den Befehl einfachmal "!skipto", was besseres fällt mir gerade nicht ein.


    "!skipto $0100" würde den ProgramCounter auf die nächste Pagegrenze setzen (untere 8 Bits werden zu 0),
    "!skipto $0010" auf die nächste 16er-Grenze (also unterste 4 Bits sind 0).


    Gibt es sowas vielleicht schon und ich übersehe es nur?


    Gruß,
    Thomas

  • Nein, gibt es AFAIK nicht, kann man jedoch selbst recht leicht nachbauen:


    !do while * < $0900 { !byte $00 }


    Die Adresse kann man ggf. ja vorher in einem Makro mit lokalen Symbolen berechnen...


    Nachtrag: Etwa so:


    !macro skipto .boundary {
    .tmp = * % .boundary
    .dest = * + (.boundary - .tmp) % .boundary
    !do while * < .dest { !byte $00 }
    }



    Verwendung:


    +skipto $0100





    oder auch:


    !macro skipto .boundary {
    .tmp = * % .boundary
    .amount = (.boundary - .tmp) % .boundary
    !skip .amount
    }

  • Geht sogar noch einfacher:


    ; Bis zur nächsten Page-Grenze 0-Bytes:
    !do while <*>0 { !byte $00 }


    Allgemeiner (z.B. wie von Freak gewünscht zur nächsten 16er Grenze):


    ; Bis zum nächsten vollen 16er 0-Bytes:
    !do while (*&$0f)>0 { !byte $00 }


    In dieser Schreibweise geht natürlich auch die Page-Grenze (wobei ich für diesen Zweck die obere Schreibweise schönder finde):


    ; Bis zur nächsten Page-Grenze 0-Bytes:
    !do while (*&$ff)>0 { !byte $00 }

  • Was ich aber noch vermisse ist ein Befehl, ähnlich dem obigen Zitat:
    Ich nenne den Befehl einfachmal "!skipto", was besseres fällt mir gerade nicht ein.

    Da gab es doch den !align, der kann doch sowas?

    Ja, genau für sowas ist der gedacht.

    Code
    1. !align $ff, 0 ; zur nächsten Pagegrenze
    2. !align $3f, 0 ; zum nächsten Spriteblock
    3. !align %####, %.##. ; zur nächsten Adresse, bei der die unteren vier Bits 0110 sind (warum auch immer).

    Der Default-Füllwert bei !align ist 234, also der NOP-Opcode. Wer mit Null oder einem anderen Wert auffüllen will, muss dies als dritten Parameter angeben.

  • Hi,
    dann schmeiße ich mal den Kompiler und laß die Test-Suite durchlaufen.
    Ist ein Test-Case für die neuen Features dabei?


    Gruß Höp

  • Ups, den habe ich übersehen...


    Zu meiner Rettung kann ich allenfalls hervorbringen, dass mein Makro allgemeiner ist. Man kann damit auch bspw. auf eine durch 100 teilbare Adresse alignen - wenn die bspw. für den Benutzer leichter zu erinnern sein soll. Mögen sich beide Möglichkeiten sinnvoll ergänzen.

  • Die ersten beiden Features finde ich sehr nützlich - Dank dafür !


    Anbei eine kompilierte Linux Ubuntu (16.04) 32 Bit-Version, wenn ich mir das richtige Archiv geschnappt hatte. Sah aber so aus. Fand da ansonsten nur Windows ... ;(

  • Neue Warnung: Zeropage-indirekte Adressierungsarten mit der Adresse $ff erzeugen eine Warnung, da das Highbyte des Pointers nicht von $0100, sondern von $00 geholt würde. Bei den 24-Bit-Pointern der 65816-CPU passiert das natürlich auch für $fe. Vielen Dank an Gerrit für den Vorschlag!

    Naja, das ist beim 65816 ja nicht generell der Fall. Gilt wohl nur für den Emulation-Mode. Im Native-Mode läuft das sehr wohl über die $FF-Grenze hinweg. Einen Wraparound gibt es hier nur in Bezug auf Bank 0, auf den die Direct Page beschränkt bleibt (die ja beliebig in der Bank mit dem Direct Page Register positioniert sein kann). Wenn, dann nur im Emulation-Mode, aber weiß das der Assembler? Macht ACME Emulation-Bit-Tracking während des Assembler-Durchläufe? Sonst fände ich eine derartige Warnung (auch wenn sie nur auf Verdacht hin gemacht wird) eher störend.

  • Wenn, dann nur im Emulation-Mode, aber weiß das der Assembler

    Eben dann erscheint mir eine Warnung sinnvoll, da es ja erst zur Laufzeit klar wird, ob es funktioniert wie vermutlich gedacht. Nach dem Argument dürfte man ja auch auf dem 6502 nicht warnen, da sich ja auch alle die Leute, die den Wraparound auf dem 6502 tatsächlich nutzen wollen gestört fühlen würden.

  • Neue Warnung: Zeropage-indirekte Adressierungsarten mit der Adresse $ff erzeugen eine Warnung, da das Highbyte des Pointers nicht von $0100, sondern von $00 geholt würde. Bei den 24-Bit-Pointern der 65816-CPU passiert das natürlich auch für $fe. Vielen Dank an Gerrit für den Vorschlag!

    Wäre schön, wenn die Warnung nur dann kommen würde, wenn die !CPU - Einstellung auf eine betroffene CPU hindeutet.


    Gibt es eigentlich eine Übersicht über solche CPU-Bugs und ob die in 6502, 6510, 65C02, 65802 bzw. 65816 vorhanden sind (ggf. nach Mode unterschieden)?

  • Eben dann erscheint mir eine Warnung sinnvoll, da es ja erst zur Laufzeit klar wird, ob es funktioniert wie vermutlich gedacht. Nach dem Argument dürfte man ja auch auf dem 6502 nicht warnen, da sich ja auch alle die Leute, die den Wraparound auf dem 6502 tatsächlich nutzen wollen gestört fühlen würden.


    Diesen Vergleich würde ich nicht unbedingt ziehen bzw. halte ihn für nicht gleichwertig. Wenn jemand z.B. die 65816 als CPU deklariert, dann gehörte eigentlich auch ein Pseudo-Opcode, ob sich eine Code-Abschnitt im Emulation- oder Native-Mode befindet, so wie es z.B. für 16- und 8-Bit-Modus bei A/M und X/Y auch gibt, damit der Assembler nicht nur den richtigen Code erzeugt, aber auch nur dann warnt, wenn es angebracht ist. Wenn ich ein LDA #$100 ist die Warnung akzeptabel, wenn A/M tatsächlich 8-Bit ist. Da kann ich aber auf eine Bevormundung durch den Assembler verzichten, wenn der im 16-Bit-Modus meint, mich zu warnen, weil der Operand die 8-Bit-Grenze überschreitet.
    Ähnlich bei JMP (address). Wenn <(address ) $FF sollte der Assembler warnen, wenn als CPU ein 6502 deklariert ist, nicht aber bei einer Deklaration als 65c02 oder 65816.


    Das ist eher eine grundsätzlich Einstellung, wie und wann man Warnungen präsentiert bekommen möchte. Wenn, dann sollte es bei einem Assembler (oder auch Compiler) auswählbar sein, ob das Ding hysterisch warnt oder nicht. Z.B. im Zuge des Developements, für den Feinschliff zur Überprüfung lass ich mir alle Warnung ausgeben und schau mir diese dann an, ob sie plausibel sind und wirklich eine Grundlage haben. Im laufenden Entwicklungszyklus muss ich nicht ständig alle möglichen Warnungen angezeigt bekommen (die womöglich von einem Status zur Laufzeit abhängen, die der Assembler ohnehin nicht überprüfen kann). Dann, wenn man den Source aus der Hand gibt, möchte (zumindest) ich, dass ein Assembler oder Compiler (sofern nicht explizit durch ein Makefile vorgegeben) mit Warnungen dem Übersetzenden irritieren, oder den Anschein erweckt, es handle sich vielleicht um einen mit heißen Nadeln gestrickten Code ...


    Also wäre mein Wunsch lediglich, dass man das so steuern kann, dass keine Warnung kommt, wenn man weiß was man tut. ;) (ungeachtet dessen, ob und wie das nun konkret für ACME geht)

  • Hallo Leute,


    ich finde es super, wenn jemand einen Compiler weiter pflegt und ständig ergänzt. Jetzt fehlt mir als Assembler-Anfänger für solche Compiler aber das passende Handbuch, vorzugsweise in deutsch, damit sich ein Programmier-Anfänger auch in diese aktuelle Syntax einarbeiten kann. Habt ihr daran schon mal gedacht. Ein Handbuch mit kurzen Beispielen zu entwickeln, damit sich auch NICHT-Experten in Euer Wissen einarbeiten können?


    Liebe Grüße!
    ThomBraxton

  • Nicht nur für den Anfang ist https://www.c64-wiki.de/wiki/ACME dafür ganz gut geeignet. Auch wenn die Neuerungen der aktuellen Version da noch nicht berücksichtigt sind.

  • Im Native-Mode läuft das sehr wohl über die $FF-Grenze hinweg.

    Danke für den Hinweis, da muss ich wohl noch mal das Datenblatt wälzen. Ein schneller Blick in den VICE-Source deutet aber tatsächlich darauf hin, dass das Emulations-Bit einen Einfluss auf das Adress-Wrapping hat.


    Je länger ich jetzt darüber nachdenke, desto mehr halte ich das Verhalten der 65816-CPU in dieser Hinsicht für inkonsequent:
    Der 6502 bleibt mit Zeropage-Zeigern immer in der Zeropage. Das kann man als Feature oder als Bug betrachten, aber der Grund für dieses Design leuchtet ein, nämlich die einfachere Implementierung.
    Eine Nachfolge-CPU könnte nun dieses Limit aufheben, so dass ($ff),y das Highbyte von $0100 holt.
    Eine Nachfolge-CPU könnte auch die Zeropage frei im Speicher verschiebbar machen.
    Aber beides zugleich? Semantisch gesehen verschiebt man dann einen direkt adressierbaren Block von 256 Adressen beliebig im Adressraum, aber für bestimmte Adressierungsarten ist dieser logische Block dann 257 oder 258 Bytes groß - d.h. es gibt Zeiger "in der Zeropage", deren zweites und/oder drittes Byte man nicht mit Zeropage-Adressierung setzen kann.

    Macht ACME Emulation-Bit-Tracking während des Assembler-Durchläufe?

    Nein. Das würde ich auch kaum versuchen wollen, da es prinzipiell nicht 100%ig sicher machbar ist.

    Wurde vielleicht schon der Patch laut Ticket #1 im Zuge dieser neuen Release berücksichtigt?

    Der ist tatsächlich schon lange implementiert, danke. Ich muss den Status des Bugs mal auf "Closed" setzen. Immer dieses Neuland... :drunk:

    Wäre schön, wenn die Warnung nur dann kommen würde, wenn die !CPU - Einstellung auf eine betroffene CPU hindeutet.

    Das ließe sich machen. Wenn die 65816-Coder diese Warnung als kontraproduktiv empfinden, baue ich das entsprechend um - ich selbst habe kaum praktische Erfahrung mit dem 65816 und würde mich da nach der Mehrheit richten.

    Gibt es eigentlich eine Übersicht über solche CPU-Bugs und ob die in 6502, 6510, 65C02, 65802 bzw. 65816 vorhanden sind (ggf. nach Mode unterschieden)?

    Wer so eine hat, möge sie mir schicken, dann baue ich die Informationen in trunk/docs/cputypes.txt mit ein.