Software > Coding

gcc crosscompiler - GEMlib

(1/5) > >>

aligator123456:
hi
ich probiere derzeit folgendes:
Dieses Guide: http://firebee.org/fb-bin/news?action=full_news&idnews=350&lng=DE&offset=0
ist ja für den AHCC und funktioniert mit diesem auch.

aber ich würde das gerne auch mit gcc machen.
dazu gibt es ja die gemlib: http://arnaud.bercegeay.free.fr/gemlib/

erster Test mit dem Beispiel VERSION1 aus den Guide:

Codetechnisch kann ich auch alles 1 zu 1 vom AHCC-Tutorial nutzen, bis auf die Importe, welche (vermutlich) durch #include <gem.h> ersetzt werden müssen und der Zeile:

--- Code: ---work_in[0] = 2 + Getrez();
--- Ende Code ---
in der window.c.
Denn Getrez() gibt es in der gemlib anscheinend nicht direkt.

nach etwas suchen hab ich das gefunden:


--- Code: ---short getrez, colors, coloricons, bitmap;
appl_getinfo(2, &getrez, &colors, &coloricons, &bitmap);       
work_in[0] = getrez;
--- Ende Code ---

dabei liefert Getrez in AHCC: 2
und in getrez bei gemlib: 4

also vermutlich kann ich des +2 dann weglassen...


so dann kompiliert das ganze auch.  :)
Aber beim ausführen wird kein Fenster angezeigt.  >:(

Gibt es eine Anleitung, wie die Gemlib korrekt zu nutzen ist?
Oder kann mir da jemand ein paar Tipps geben?

czietz:
Welche Version des gcc?

Getrez() ist eine XBIOS-Funktion, die das Einbinden der geeigneten Header-Datei nötig macht. Allerdings ist Deine Lösung, AES zu nutzen, ohnehin empfehlenswert. Die Nutzung von Getrez() in einem AES-Programm, wie in Peter Lanes Guide, sollte vermieden werden. Zitat aus TOS.HYP zu Getrez(): "Hinweis: Vom Standpunkt der sauberen Programmierung betrachtet, sollte diese Funktion auf keinen Fall benutzt werden."

Bei der Portierung der Sourcen auf gcc muss beachtet werden, dass für AHCC der Datentyp "int" 16 Bit breit ist, für gcc (standardmäßig) aber 32 Bit. Leider verwendet Peter Lane in seinem Guide immer "int" statt Datentypen wie int16_t mit fest definierter Bitbreite, das ist nicht besonders schön! gcc kann grundsätzlich mit der Option "-mshort" auf 16-Bit-"int"s umgestellt werden; dann ist aber zu beachten, dass alle verwendeten Bibliotheken auch mit "-mshort" kompiliert worden sein müssen.

In Vincent Rivières gcc-Distribution liegt zumindest die GEMLIB in Versionen mit und ohne -mshort vor, viele andere Bibliotheken aber nun nicht.

czietz:
PS: Angehängt ein auf die schnelle portiertes Beispiel "VERSION1". Es compiliert mit Vincent Rivières m68k-atari-mint-gcc sowohl mit als auch ohne -mshort und funktioniert auch. Die ganzen "Unsauberkeiten" des ursprünglichen Autors habe ich bewusst nicht beseitigt.

Wenn Du die Dateien vergleichst, siehst Du, welche Änderung in etwa nötig sind, um die weiteren Beispiele von AHCC nach gcc zu portieren.

aligator123456:
Vielen Dank!  :)

Das hat mir schonmal etwas weitergeholfen.
Ich nutze den neuesten gcc von Vincent.

Das Getrez() nicht genutzt werden sollte hab ich auch irgendwo gelesen gehabt. Allerdings stand dort nicht, wie man es "richtig" macht.
Die appl_getinfo() - Funktion hab ich dann auf der Suche nach einer Alternative in der Doku von der GEMlib gefunden.
Du hast geschrieben dass meine Lösung empfehlenswert ist. Also ist das die "saubere" Methode?

Allgemeine Frage hierzu:
Wann ist ein GEM-Programm sauber und wann nicht? Was sollte man vermeiden?

Ich werde dann demnächst auch mal probieren die anderen Beispiele zu portieren. :)

goetz @ 3rz:

--- Zitat von: aligator123456 am Sa 14.01.2017, 00:10:39 ---Wann ist ein GEM-Programm sauber und wann nicht? Was sollte man vermeiden?

--- Ende Zitat ---

Das ist Thema für ganze Bücher („Von Anfänger zum GEM-Profi“, Geiß&Geiß; Profibuch; Atari Compendium) und lange Abhandlungen – gute Zusammenfassungen: von J. Reschke im ST-Magazin, aber auch von U. Seimet. Und es unterlag einem Wandel der Zeit. Was 1988 noch sauber war, mußte es 1993 nicht mehr zwangsläufig sein. Am Anfang gab es noch keine Cookies, so mußten Applikationen auch öfter böse im Sand stochern, was die Hardware angeht. Manchmal war ein Supervisor-Aufruf unumgänglich, und wie man den möglichst sauber initiiert, kann ausgehen wie der Streit ob C64 oder Atari 800 besser sei …

Kein selbstmodifizierender Code wegen „moderner“ CPU-Caches. Generell sollte man so wenig „tiefe“ Systemschichten (BIOS/XBIOS - oder gar LINE-A) wie möglich aufrufen, und so wenig Annahmen über zugrundeliegende Hard- & Software treffen wie möglich. Man beschränkt sich auf AES, VDI und GEMDOS. Das ist ein Anfang. Dazu ein guter Haufen generelle Hinweise wie „Thou shalt not mess with memory thou ownest not“, http://dev-docs.atariforge.org/files/Pexec_Cookbook_9-6-1991.pdf und immer damit rechnen, dass Funktionen nicht nur positive Rückgabewerte haben können, und dass zwei Anweisungen hintereinander mit Abhängigkeiten untereinander auch von einem Drittprogramm unterbrochen werden können, die die Abhängigkeit stört – das berühmte Malloc(Malloc(-1L)) muß weder klappen, noch ist es nett zu anderer Software.

Es kommt natürlich auch immer darauf an, was du erreichen willst. Muss das Programm noch auf einem Rechner mit TOS 1.0 mit 512 KB RAM laufen, soll aber A4-Seiten grafisch bedrucken? Dann wird es mit GDOS alleine schwierig, außer du nutzt OUTPUT.APP, aber das kannst du auch nicht voraussetzen. Bei solchen harten Bedingungen wird es schwierig, „generisch“ zu gewinnen; entweder machst du Fallunterscheidungen, oder programmierst viel Funktionalität nach, die eigentlich wo anders reingehört.

Wenn es hinterher auf MiNT mit Speicherschutz (damit weiß man, dass man nicht in fremdem Speicher rumschreibt), einem 68060 (sauberes Cache-Handling), auf MagiCMac (kein Zugriff auf eher zu meidende Systemvariablen), einem TOS 1.04 (das unterste dessen, was ich noch unterstützen würde) sowie auf Farbgrafikkarten (keine falschen Annahmen über den Aufbau des Bildschirms) sauber läuft und auf GDOS-Druckern druckt, ist man schonmal auf einem guten Weg.

Navigation

[0] Themen-Index

[#] Nächste Seite