gcc crosscompiler - GEMlib

[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: [Auswählen]

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

nach etwas suchen hab ich das gefunden:

Code: [Auswählen]

short getrez, colors, coloricons, bitmap;
appl_getinfo(2, &getrez, &colors, &coloricons, &bitmap);       
work_in[0] = getrez;
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]

Wann ist ein GEM-Programm sauber und wann nicht? Was sollte man vermeiden?

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.

[KarlMüller]

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

Dies bezieht sich nur darauf, das über den Rückgabewert keine Aussage über die Auflösung gemacht werden kann. Wenn ich nicht falsch bin wird z.B. beim Falcon fünf zurück geliefert. Das verstehen dann Programme nicht und meinen es sei eine falsche Auflösung vorhanden.

Die Lösung mit appl_getinfo hat den Nachteil das diese Funktion erst ab einer bestimmten AES Version vorhanden ist. Wenn sie nicht da ist wird es zu einer Fehlermldung des Systems kommen.

[czietz]

Dies bezieht sich nur darauf, das über den Rückgabewert keine Aussage über die Auflösung gemacht werden kann. Wenn ich nicht falsch bin wird z.B. beim Falcon fünf zurück geliefert. Das verstehen dann Programme nicht und meinen es sei eine falsche Auflösung vorhanden.

Die Lösung mit appl_getinfo hat den Nachteil das diese Funktion erst ab einer bestimmten AES Version vorhanden ist. Wenn sie nicht da ist wird es zu einer Fehlermldung des Systems kommen.

Ich habe nochmal nachgelesen und Du hast Recht. In diesem speziellen Fall (Öffnen der virtuellen Workstation) ist die Nutzung der XBIOS-Funktion Getrez() sicherlich gerechtfertigt und vermutlich die Lösung, die unter den meisten TOS-Versionen funktioniert. Da das Abertausende von GEM-Programmen so machen -- immerhin hat Atari das im "GEM Programmer's Guide" einst genau so vorgegeben --, kann man auch davon ausgehen, dass z.B. Grafikkartentreiber das falls nötig abfangen und das Öffnen der virtuellen VDI-Workstation somit auch dann klappt, wenn der Rückgabewert von Getrez() eigentlich keine Aussagekraft mehr hat -- z.B. bei Bildschirmauflösungen, die nicht ST- oder TT-Standard entsprechen.

Was 1988 noch sauber war, mußte es 1993 nicht mehr zwangsläufig sein.

Da das von aligator123456 genutzte Tutorial von 2016 ist, würde ich erwarten, dass es "State-of-the-Art" GEM-Programmierung beschreibt und nicht auf den Stand von 1988.

[goetz @ 3rz]

Da das von aligator123456 genutzte Tutorial von 2016 ist, würde ich erwarten, dass es "State-of-the-Art" GEM-Programmierung beschreibt und nicht auf den Stand von 1988.

Zum einen fragte der OP "was ist sauber" und nicht "ist mein Tutorial sauber", zum anderen hat das Erscheinungsdatum ja nicht notwendigerweise was mit der Richtigkeit des Inhalts zu tun.

Aber gut, dann schauen wir mal, ob "ist mein Tutorial sauber" bzw. "auf dem Stand 2016" als Fragestellung was interessantes abgibt …

   wd.handle = wind_create (NAME|CLOSER, fullx, fully, fullw, fullh);
   wind_set_str(wd.handle, WF_NAME, "Example: Version 1");
   wind_open (wd.handle, fullx, fully, 300, 200);

In dem Codeschnipsel wird bspw. nicht geprüft, ob wind_create einen Fehler liefert, stattdessen wir mit diesem Rückgabewert als Handle einfach das Fenster geöffnet. Das war auch schon 1988 keine gute Idee. Auch v_opnvwk wird verwendet ohne zu prüfen, ob das gutging.

In "VERSION8" wird fsel_exinput aufgerufen, obwohl es das erst ab TOS 1.04 gibt, ohne Prüfung. Das gibt unter TOS 1.0/1.02 Ärger.

Und spätestens bei dem Schnipsel hier:

      char * filename = malloc (sizeof(char) * (strlen(path)+strlen(name)));

      /* connect path+name to form complete filename */
      strcpy (filename, path);

(VERSION8, "main.c")

… bin ich raus: Versuchen Speicher zu allozieren und in den reinzuschreiben, egal ob der auch erfolgreich angefordert werden konnte. D.h. im Zweifel schreibt die Software nach Adresse 0 (denn das wäre der Fehlercode)  und da hagelt es dann Bomben. Ne, das ist nicht nur nicht der Stand von 2016, das ist nichtmal der Stand von 1988.

Ich würde also zusammenfassend mich von diesem 2016er Tutorial abwenden und lieber die von mir vorher angeführten Werke lesen:

• D. Geiß, J. Geiß: Vom Anfänger zum GEM-Profi; ISBN 978-3778521823
  
• S. Maguire: Writing solid code; ISBN 1-55615-551-4; http://cs.brown.edu/courses/cs190/2008/documents/restricted/Writing%20Solid%20Code.pdf
• Jankoswki, Rabich, Reschke: Atari Profibuch ST-STE-TT; ISBN 3-88745-888-5; http://atariprofibuch.de
• J. Reschke: Atarium; Artikelserie im ST-Magazin; http://www.stcarchiv.de/
• L. Prüßner: Artikelserien im ST-Magazin; http://www.stcarchiv.de/
• U. Seimet: viele Artikel in diversen ST-Magazinen; http://www.stcarchiv.de/

[mfro]

...
Und spätestens bei dem Schnipsel hier:

Code: [Auswählen]

char * filename = malloc (sizeof(char) * (strlen(path)+strlen(name)));

/* connect path+name to form complete filename */
strcpy (filename, path);


Abgesehen von den schon erwähnten Fehlern ist - so es denn klappt - der allokierte Speicherbereich jedenfalls um ein Byte zu kurz. Das gibt früher oder später mit großer Wahrscheinlichkeit so oder so ein Problem ...

[aligator123456]

Danke für die Infos!
Da hab ich dann erstmal genug Lesestoff

[ari.tao]

Was Du in #4 geschrieben hast, @gh-baden , das sollte wirklich jeder Programmierer verinnerlichen. Was jedoch die Lit.-Liste in #7 angeht, so stellt allein schon das Zusammensuchen eine hübsche Anstrengung für Anfänger dar.
Für Fortgeschrittene empfehle ich noch diesen Freeware-Text von Ulrich Kaiser, -> Anhang.

[goetz @ 3rz]

Was jedoch die Lit.-Liste in #7 angeht, so stellt allein schon das Zusammensuchen eine hübsche Anstrengung für Anfänger dar.

Meinst du das kompilieren der Liste (okay, wenn man nicht im Thema ist, kann man schlecht Buchtitel raten – aber darum fragte der Autor ja, und bekam ja auch hier Tipps), oder das auftreiben der tatsächlichen Titel? Das meiste davon gibt es ja inzwischen online.

Für Fortgeschrittene empfehle ich noch diesen Freeware-Text von Ulrich Kaiser, -> Anhang.

Ja, da ist gutes Zeuch bei, stimmt.

[ari.tao]

^^-- Meinte nadürlich

...oder das auftreiben der tatsächlichen Titel?... 

wenn man sich durch die Mags wühlen muß, oder in der Bucht den Geißen auflauern  .

[goetz @ 3rz]

wenn man sich durch die Mags wühlen muß,

Ooochjo, bissl Schmerz muss sein.

oder in der Bucht den Geißen auflauern  .

Jop, taucht aber immer wieder mal auf, auch auf zvab.com

[ari.tao]

^^-- 13,90 + 2,- Euro.
War das nicht der Neupreis?

PS: "Qual mich!" bat der Masochist den Sadisten. Antwortete der: "NEIN!!!"

[czietz]

oder in der Bucht den Geißen auflauern  .

Jop, taucht aber immer wieder mal auf, auch auf zvab.com

Oder man wird auf http://dev-docs.atariforge.org/ fündig.

[ari.tao]

^^-- tatsächlich, mit dem Suchwort ´GEM-Profi´ findet man es. 

[aligator123456]

supi 

und wo könnte ich die zugehörige Floppy bekommen? (Oder is da nix Wichtiges drauf...)

[goetz @ 3rz]

supi 

und wo könnte ich die zugehörige Floppy bekommen? (Oder is da nix Wichtiges drauf...)

Dort ist eine Library (im Quelltext) mit Demoquelltexten drauf. Die Bedeutung für heute ist weniger die, dass man die Lib 1:1 nutzt, dafür ist sie fast zu alt, und Kompatibilität zu FlexOS in der Praxis doch wenig bedeutend. Aber zum studieren ist es guter Stoff.

User 'mfro' hat in einem Thread vor drei Jahren hier nach der Diskette gefragt, vielleicht hat er sie ja erhalten. Ich habe meine gerade nicht zur Hand, leider.

[KarlMüller]

Dort ist eine Library (im Quelltext) mit Demoquelltexten drauf. Die Bedeutung für heute ist weniger die, dass man die Lib 1:1 nutzt, dafür ist sie fast zu alt, und Kompatibilität zu FlexOS in der Praxis doch wenig bedeutend.

Die Library ist in Phoenix. https://github.com/freemint/phoenix

Hatte ich mir mal vor Jahren angeschaut, scheint mir gegenüber der Library der Diskette aktueller zu sein.