Neues ACME-Release

Sehr schön

Zitat von Mac Bacon

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
}

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

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 }

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

Zitat von Mac Bacon

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.

Wurde vielleicht schon der Patch laut Ticket #1 im Zuge dieser neuen Release berücksichtigt? Ich hätte das für eine Kleinigkeit gehalten, die man so nebenbei mal mitnehmen könnte ... oder doch etwas komplizierter als gedacht?

Zitat von JeeK

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.

Zitat von Mac Bacon

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)?

Zitat von Claus

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)

Zitat von markusC64

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
}

Alles anzeigen

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.