Gibt es einen Cross-Assembler für den 65816 ?
Ganz wichtig ist, dass dieser Assembler den REP und SEP Befehl richtig umsetzt.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von JeeK am
Gibt es einen Cross-Assembler für den 65816 ?
Ganz wichtig ist, dass dieser Assembler den REP und SEP Befehl richtig umsetzt.
Siehe Signatur. REP und SEP werden natürlich "richtig umgesetzt", aber die Auswirkungen auf die Registerlängen werden nicht automatisch nachgezogen, denn das würde ja schon bei PHP versagen. Wer sowas will, muss sich Makros definieren.
Siehe Signatur. REP und SEP werden natürlich "richtig umgesetzt", aber die Auswirkungen auf die Registerlängen werden nicht automatisch nachgezogen, denn das würde ja schon bei PHP versagen. Wer sowas will, muss sich Makros definieren.
Habe mich da ein wenig blöde ausgedrückt,ich meinte natürlich auch die Registerlänge.
OK. dann halt Makros. Schade, ich dachte dass es einfacher wäre.
Gruß: Stephan
OK. dann halt Makros. Schade, ich dachte dass es einfacher wäre.
Ich könnte relativ schnell ein automatisches Tracking hinzufügen (per Kommandozeilen-Option hinzuschaltbar), aber wer das einsetzt, muss halt wissen, dass es keine Universallösung ist. Oben habe ich PHP als Problem genannt, ich meinte natürlich PLP...
Ich könnte relativ schnell ein automatisches Tracking hinzufügen (per Kommandozeilen-Option hinzuschaltbar), aber wer das einsetzt, muss halt wissen, dass es keine Universallösung ist. Oben habe ich PHP als Problem genannt, ich meinte natürlich PLP...
PHP.. das hatte ich völlig übersehen
Den Code kann man ja noch mittes Action Replay eintippen.
Ich wollte eingendlich mal etwas mittes SCPU testen. Das wollte ich eigendlich schon seit Jahren.
Nur ist das etwas umfangreicher. Deswegen die Frage nach einem Assembler.
Evtl. funktioniert für Dich ja der Merlin 32 Cross Assembler.-- Link
Danke für den Link.
Gleich mal ausprobieren
Ich sehe gerade, diese Seite kenne ich.
Ich hatte mir mal den Quellcode zum Artikel "LZ4 Data Compression" angesehen.
Nur leider konnte der Decompressor maximal 64KB depacken.
Gruß: Stephan
Ich wollte eingendlich mal etwas mittes SCPU testen. Das wollte ich eigendlich schon seit Jahren.
Nur ist das etwas umfangreicher. Deswegen die Frage nach einem Assembler.
Vermutlich nur ein Typo:
ldx #c104 SCPU lo & hi
->
ldx $c104 SCPU lo & hi
Am Schluss vielleicht noch ein CLI ...
Was noch unklar ist: Wer befüllt $C10x bzw. wo kommt das her. Es wird ja die Quellbank außerdem durch self-modifying geändert:
D.h. die Quellbank (3. Byte der Befehlssequenz) kommt also eigentlich aus $c106 ... (nicht notwendigerweise 02).
Alles anzeigenVermutlich nur ein Typo:
ldx #c104 SCPU lo & hi
->
ldx $c104 SCPU lo & hi
Am Schluss vielleicht noch ein CLI ...
Was noch unklar ist: Wer befüllt $C10x bzw. wo kommt das her. Es wird ja die Quellbank außerdem durch self-modifying geändert:
D.h. die Quellbank (3. Byte der Befehlssequenz) kommt also eigentlich aus $c106 ... (nicht notwendigerweise 02).
Ja, das ist ein Tippfehler. Da sollte eigendlich ein $ vor um ein 16Bit Wert in A,X,Y zu laden
Ich hatte den Code vor einigen Wochen einfach so, als Überlegung in eine txt-Datei geschrieben.
Hierbei ging es um die Adaption der REU-Commandes an die SCPU.
Das benötigte ich, um einige REU-Kopierprogramme an die SCPU anzupassen.
In die REU schreiben
Aus der REU lesen
Speicherbereiche tauschen (Swap)
Es könnten Fehler enthalten sein. Wie gesagt es handelt sich nur um eine Auslotung der Möglichkeit
Unten ist der Originla Code
So ist das dann im Programm "Ex-OR-Diskkopy" verwirklicht worden.
Das könnte man mit Sicherheit noch besser machen. Es funktioniert aber auch so.
Für ein Projekt, das mit dem C32 Makro-Assembler implementiert war, brauchte ich ein Äquivalent, dass auch auf Linux laufen sollte. C32 ist dem Autor zufolge nur noch für DOS verfügbar. Da ich kein Freund von DOSbox-Herumgefrickle bin, war mir eine native Lösung wesentlich lieber.
Mein erster Gedanke war natürlich ACME zu verwenden. Aber leider bauten die Originalquellen auf dem bei Assemblern üblichen Makrokonzept auf, nämlich, dass Parameter rein textuell ersetzt werden, wohingegen ACME eine Typisierung bei Makroparametern vorsieht. Auch nett, aber damit lassen sich wirkliche Makrosachen (siehe auch m4 unter Unix/Linux) in üblicher Verwendung (Übergabe von Strings) leider nicht realisieren (Mac Bacon weiß davon, aber eine andere Implementierung dürfte recht aufwändig sein).
Nun, das hat mich bewogen zu TASS 64 zu wechseln. http://sourceforge.net/projects/tass64/
Damit ging's dann.
Problematisch können dann noch immer Scoping von Parametern bei Makros oder Sichtbarkeit von globalen oder lokalen Labels und Variablen. Der erlaubte Zeichenumfang wie auch signifikante Länge von Labels bergen auch so manche Hürde. Auch bei den Operatoren und der Ausdrucksmächtigkeit bei bedingter Assemblierung scheidet sich Spreu vom Weizen (da kann man leider auch nicht bei allen Assemblern von einer vollständigen Funktionsmenge ausgehen).
Interessant fand ich bei der Originalvorlage bzw. der C32-Syntax, das hier keine Direktiven !rl, !rs oder !al, !as (von ACME) notwendig sind, da durch die Wahl der CPU automatisch alle Immediate-Parameter als 16-Bit gelten, es sei denn, es wird mit z.B. LDA #<$0f ein 8-Bit-Wert erzwungen. Dass das Programm zur Laufzeit an der Stelle mit A/M-Flag = 1 (8-Bit-Zugriffe für Akku und Memory) muss der Programmierer aber mit REP/SEP sicherstellen.
Ich könnte relativ schnell ein automatisches Tracking hinzufügen (per Kommandozeilen-Option hinzuschaltbar), aber wer das einsetzt, muss halt wissen, dass es keine Universallösung ist. Oben habe ich PHP als Problem genannt, ich meinte natürlich PLP...
Ein Tracking kann hier nie perfekt sein. Wenn man Code-Reuse betreibt und zu einem REP/SEP zurück springt, bekommt der Assembler die Dynamik des Programmlaufs gar nicht mit. Auf so etwas würde ich mich nicht verlassen wollen. Es wird ja oben ja auch gewarnt, dass es keine Universallösung wäre. So etwas kostet schon schnell mal einige Stunden bei der Fehlersuche ...
Der Ansatz von C32, wie ich ihn bereits zuvor geschildert habe, entweder mit Direktiven den Assembler hinweisen, wie er Immediate-Werte assembliert oder mit einem entsprechenden Operator für den Wert den Assembler auf 16 oder 8 Bit festlegen ... Ob dann zur Laufzeit die CPU wirklich an der Stelle im richtigen Modus ist, kann ein Assembler sowieso nie wirklich überprüfen (mag sich wohl auf das Halte-Problem der Informatik zurückführen lassen).
Makros würde aber schon alleine deswegen nehmen, weil die konkreten SEP/REP-Befehle für das jeweilige Umstellen der Datenbreite nicht intuitiv und fehlerträchtig sind und sprechendere Namen verdient haben. Nur wenn man vielleicht ein CLC/SEC wegoptimieren möchte, kann man sich wieder auf die Niederungen des SEP/REP-Arguments herablassen.