atari-home.de - Foren
Software => Coding => Thema gestartet von: simonsunnyboy am So 03.11.2013, 15:14:04
-
Hallo zusammen,
wie ich gerade feststellen musste, hat der GNU as einen ziemlichen anderen, um nicht obskuren Syntax.
Kann mir daher jmd sagen, wie ich a) folgendes Codestück mit Devpac/TurboAssembler/PureC/AHCC Syntax auf den GNU as Syntax für meinen Crsscompiler umbiege
; *******************************************
; clear truecolor screen 320x240 pixels at a0
; *******************************************
TC320x240_CLS:
movem.l d0-a6,-(sp)
move.l #((320*240/16)-1),d0
lea clrbuf(PC),a1
movem.l (a1),d1-d7/a2
clrloop:
movem.l d1-d7/a2,(a0)
lea 32(a0),a0 ; 32 = 4*8 bytes
dbra d0,clrloop
movem.l (sp)+,d0-a6
rts
clrbuf: DC.L 0,0,0,0,0,0,0,0
EVEN
und b) ob da ggfs Coldfire unverträgliche Opcodes drin sind? Ich versuch aktuell mit dem gcc 030/Coldfire kompatibeles Zeugs zu erzeugen, und nebenbei vom AHCC auf gcc zu wechseln...
Grüße,
ssb
-
a)
| *******************************************
| clear truecolor screen 320x240 pixels at a0
| *******************************************
TC320x240_CLS:
movem.l d0-a6,-(sp)
move.l #320*240/16-1,d0
lea clrbuf(PC),a1
movem.l (a1),d1-d7/a2
clrloop:
movem.l d1-d7/a2,(a0)
lea 32(a0),a0 | 32 = 4*8 bytes
dbra d0,clrloop
movem.l (sp)+,d0-a6
rts
clrbuf: DC.L 0,0,0,0,0,0,0,0
.align(2)
b)
bis auf die movem's (Coldfire kann kein movem mit Prädekrement oder Postinkrement) und dbra (gibt's im Coldfire-Befehlssatz nicht mehr) ist die Codesequenz "Coldfire-clean".
-
Danke für die schnelle Antwort, mit nachgeschobenem *würg*
Gerade die movems sind sowas von nützlich :(
Ich schätz, ich kompilier wieder nur für 030 und Bienenuser müssen halt FireTOS nehmen...
Die Callingconvention beim gcc ist immer noch a0-a1 für Adressen, d0-d2 für normale Variablen?
(Meine bisherigen Disassemblies scheinen das zu bestätigen, ich möchte nur sichergehen.)
-
Danke für die schnelle Antwort, mit nachgeschobenem *würg*
Gerade die movems sind sowas von nützlich :(
Ich schätz, ich kompilier wieder nur für 030 und Bienenuser müssen halt FireTOS nehmen...
Wo liegt das Problem?
68000:
movem.l d0-a6, -(sp)
Coldfire:
lea -15 * 4(sp),sp
movem.l d0-a6, (sp)
Die Callingconvention beim gcc ist immer noch a0-a1 für Adressen, d0-d2 für normale Variablen?
(Meine bisherigen Disassemblies scheinen das zu bestätigen, ich möchte nur sichergehen.)
gcc übergibt alle Variablen auf dem Stack. War das die Frage?
-
Wenn die 2 Befehle gleich viele Zyklen auf dem 030 brauchen wie das movem mit Post/Prädekrement, könnte ich es mir überlegen....
"Alles auf dem Stack" ist eine Antwort, auch die macht mir ein *würg*, und fast noch ein größeres als die fehlenden Opcodes :P
Ich fürchte, gcc/gas ist für Atari keine Option, wenn man halbwegs syntaxkompatiblen und unsauberen Code (Demos/Games) schreiben will. Für sauberen Kram wohl ne gute Wahl....
Sieht schwer danach aus, daß ich doch bei AHCC bleiben werde....
-
"Alles auf dem Stack" ist eine Antwort, auch die macht mir ein *würg*, und fast noch ein größeres als die fehlenden Opcodes :P
Ich fürchte, gcc/gas ist für Atari keine Option, wenn man halbwegs syntaxkompatiblen und unsauberen Code (Demos/Games) schreiben will. Für sauberen Kram wohl ne gute Wahl....
Da bin ich anderer Ansicht.
AHCC ist zwar ein ganz nettes Programm, aber die Codeoptimierung ist bislang noch nicht aus den Kinderschuhen herausgekommen (ähnliches gilt übrigens auch für Pure/Turbo-C).
Der Code von gcc steckt den von AHCC gaaanz locker in die Tasche. Die Parameterübergabe auf dem Stack ist nur bei sehr kurzen Unterprogrammen von Nachteil und die kann gcc problemlos - ohne daß man extra was dazu tun müsste - inlinen.
Abgesehen davon darf ein Compiler, der Threads unterstützt, gar keine Parameterübergabe in Registern machen. Das geht sonst schief.
Gcc ist sehr viel mächtiger als AHCC. Nur zwei Beispiele: mit der Möglichkeit des Inline-Assemblies beim gcc lassen sich alle möglichen Schweinereien anstellen, mit dem __attribute__((interrupt)) direkt Traphandler und Interrupt-Routinen in C schreiben.
Wenn man sich mal daran gewöhnt hat, sind die anderen Compiler nur noch Spielzeug.
-
Abgesehen davon darf ein Compiler, der Threads unterstützt, gar keine Parameterübergabe in Registern machen. Das geht sonst schief.
Das ist so Unfug, da bei einem Kontext-Wechsel natürlich auch die Register gesichert werden und damit der aufgerufenen Funktion in jedem Fall unverändert zur Verfügung stehen. Das wird selbst bei Userland-Thread-Bibliotheken so gehandhabt, da alles andere viel zu fehleranfällig wäre.
Ansonsten gebe ich Dir aber in allen Punkten recht.
-
Abgesehen davon darf ein Compiler, der Threads unterstützt, gar keine Parameterübergabe in Registern machen. Das geht sonst schief.
Das ist so Unfug, da bei einem Kontext-Wechsel natürlich auch die Register gesichert werden und damit der aufgerufenen Funktion in jedem Fall unverändert zur Verfügung stehen. Das wird selbst bei Userland-Thread-Bibliotheken so gehandhabt, da alles andere viel zu fehleranfällig wäre.
Da hab ich wohl ein wenig unsauber formuliert. Natürlich müsen die Register gesichert werden. Aber wo werden die gesichert? Eben. ;)
-
Trotz aller Vorteile würde das für mich einen kompletten Rewrite und erneuten Test vorhandenen Codes bedeuten...den Aufwand will ich aktuell nicht investieren, ich komm so schon kaum dazu an meinen eigentlichen Projekten zu schaffen.