Fortran (gfortran) für ST

[Thorsten Otto]

Wie in dem anderen Thread geschrieben, habe ich mal versucht den fortran-compiler von GNU zu bauen, sowohl als cross-compiler als auch native. Lässt sich auch ohne Schwierigkeiten übersetzen, erzeugt auch brav ST Programme, leider funktionieren diese nicht

Ich selber hab leider überhaupt keine Ahnung von Fortran (einige der wenigen Sprachen die ich nicht beherrsche , vlt halt ja jemand ne Idee. Versucht hab ich es mit erstmal mit folgenden Programmen:

Code: [Auswählen]

      print *, "Hello, world"
      END

Ergebnis: bricht ab mit

Code: [Auswählen]

Fortran runtime error: End of record
Programm 2:

Code: [Auswählen]

      CHARACTER(len=*), parameter :: str = "Hello, world"//achar(10)
      INTEGER :: i
      DO i = 1, len_trim(str)
         CALL fput(str(i:i))
      END DO
      END

Ergebnis: läuft normal durch, gibt aber nix aus..

Irgendeiner 'ne Idee, was da falsch läuft? Hatte erst gedacht es würde als cross-compiler nicht gehen, für mingw funktioniert es aber, und andere haben wohl auch schon Versionen für ARM gebaut.

[gh-baden]

Wie in dem anderen Thread geschrieben, habe ich mal versucht den fortran-compiler von GNU zu bauen, sowohl als cross-compiler als auch native. […]

Irgendeiner 'ne Idee, was da falsch läuft? Hatte erst gedacht es würde als cross-compiler nicht gehen, für mingw funktioniert es aber, und andere haben wohl auch schon Versionen für ARM gebaut.

https://s1.hoffart.de/~goetz/collatz/Atari-ST/Prospero-Fortran/COLLATZ.FOR.txt  – tut mit Atari Prospero Fortran.

[czietz]

Wenn Du mir eine Version für Windows (cygwin oder mingw) erstellst, probiere ich gerne mit. Auch wenn ich -- wie gesagt -- auch nur Fortran-Einsteiger bin.

[Thorsten Otto]

tut mit Atari Prospero Fortran.

Danke, aber in dem Fall geht es darum einen frei erhältlichen fortran-compiler zu haben, um z.B. den original linpack-benchmark übersetzen zu können.

Wenn Du mir eine Version für Windows (cygwin oder mingw) erstellst, probiere ich gerne mit

Bitte schön (für cygwin32):

http://tho-otto.de/download/mint/gcc-8.3.0-mint+fortran-bin-cygwin32.tar.xz
http://tho-otto.de/download/mint/gcc-8.3.0-mint+fortran.tar.xz

Script und Bin-Archive sollten identlsch zum normalen Download sein, einzige Änderung:

Code: [Auswählen]

--- build-gcc.sh.orig   2019-02-26 03:46:31.101356331 +0100
+++ build-gcc.sh        2019-02-25 18:53:07.470170047 +0100
@@ -204,7 +204,7 @@
 
 enable_lto=--disable-lto
 enable_plugin=--disable-plugin
-languages=c,c++
+languages=c,c++,fortran
 ranlib=ranlib
 STRIP=${STRIP-strip -p}

Wenn du rumprobierst, musst du es allerdings sowieso neu übersetzen. Wenn du das beiliegende Script benutzt, werden die Programme in einem Verzeichnis  binary7-package erzeugt (von dort, wo du das Script startest). Dort sollten vorher die cross-binutils vorhanden sein (zumindest mach ich das so, bin mir gerade nicht so sicher obs auch funktioniert wenn er sich die z.B. aus /usr/bin holt).

Übersetzen dauert bei mir (VirtualBox auf linux mit I7, mit einer emulierten CPU) ca 50min. Auf echter Hardware, vor allem mit parallelen Jobs, dürfte es schneller gehen (für linux sinds knapp 5min).

Oh, und noch eine Sache: um die libgfortran zu übersetzen, brauchst du einen kleinen patch in mintlib für math.h, den ich erst letztens gepusht habe (nextafter muss dort deklariert sein).

Vermutlich musst du auch noch einige Pakete installieren. Spontan fallen mir da flex, bison, isl, mpc, gmp, mpfr ein. Ansonsten bei Fragen einfach anschreiben

[czietz]

Hm, also ich habe damit sowohl Dein Hello-World als auch das 1000d.f compiliert. Laufen beide. Einziges Problem: sie machen eben nur einen Line-Feed als Zeilenumbruch, d.h. die Textdarstellung auf dem Bildschirm ist unschön.

[Thorsten Otto]

Hm, also ich habe damit sowohl Dein Hello-World als auch das 1000d.f compiliert. Laufen beide.

Oh, stimmt auffallend, funktioniert bei mir auch. Seltsam. Muss ich mir mal nochmal anschauen, vlt. sind da noch irgendwelche Probleme wegen 64 vs 32bit. beim cross-compilieren.

Einziges Problem: sie machen eben nur einen Line-Feed als Zeilenumbruch, d.h. die Textdarstellung auf dem Bildschirm ist unschön.

Daß nur ein linefeed ausgegeben wird ist aber normal. Für den Rest sollte die mintlib sorgen, wenn die Ausgabe auf einen Bildschirm geht, und tut sie bei mir auch wenn ich es in einem toswin2 Fenster laufen lasse.

[czietz]

Daß nur ein linefeed ausgegeben wird ist aber normal. Für den Rest sollte die mintlib sorgen, wenn die Ausgabe auf einen Bildschirm geht, und tut sie bei mir auch wenn ich es in einem toswin2 Fenster laufen lasse.

Tut sie aber nicht -- getestet unter Atari TOS und unter EmuTOS in der EmuCON.

Außerdem: Ist es wirklich normal, dass nur ein LF ausgegeben wird? Fortran arbeitet ja mit dem abstrakten Konzept von Datensätzen (Records). Es ist Aufgabe der Fortran-Laufzeitbibliothek, den passenden Datensatztrenner zum jeweiligen Ausgabestream zu generieren. Das kann eine völlig andere Aktion sein, abhängig davon ob die Ausgabe auf ein Terminal, einen Lochkartenstanzer oder auf ein datenbank-orientiertes VAX-VMS-Dateisystem geht. libgfortran hat -- soweit ich das sehen kann -- ein eigenes Define HAVE_CRLF dafür, dass der Trenner bei Textausgabe CR+LF sein soll, was imho auf dem Atari auch sein müsste.

[Thorsten Otto]

Tut sie aber nicht -- getestet unter Atari TOS und unter EmuTOS in der EmuCON.

Dann müsste man sich nochmal anschauen was mintlib da unter plain TOS macht.

Außerdem: Ist es wirklich normal, dass nur ein LF ausgegeben wird?

Ja, ansonsten müsstest du ja jedes Programm ändern (auch C), und dort explizit CR/LF ausgeben.

ibgfortran hat -- soweit ich das sehen kann -- ein eigenes Define HAVE_CRLF dafür, dass der Trenner bei Textausgabe CR+LF sein soll.
[/quote]

Ja, hab mittlerweile auch gesehen. Für unix aber nicht, und mintlib sollte sich da eigentlich kompatibel verhalten (gibt ja auch zb. auch kein O_BINARY für Datei Handles).

was imho auf dem Atari auch sein müsste

Wird eigentlich auch gemacht, wenn mintlib feststellt daß die Ausgabe auf ein Terminal geht.

Kannst ja mal ausprobieren, was bei einem entsprechenden C-Programm passiert.

PS.: hab zwar die Ursache noch nicht gefunden, aber die cygwin64-version des compilers hat die gleichen Probleme wie die linux-version.

[czietz]

Außerdem: Ist es wirklich normal, dass nur ein LF ausgegeben wird?

Ja, ansonsten müsstest du ja jedes Programm ändern (auch C), und dort explizit CR/LF ausgeben.

Eben nicht. In C habe ich natürlich ein Programm mit printf("...\n") und will das nicht ändern müssen, nur damit es auf einem System mit CR+LF läuft. Aber in Fortran habe ich sowieso das Konzept des abstrakten Datensatztrenners. D.h. ich muss das Programm nicht ändern, die Runtime-Bibliothek sorgt dafür, dass ich die für das jeweilige Betriebssystem bzw. Ausgabegerät korrekten Zeichen bekomme. Ob nun libgfortran oder die MinTLib darunter das CR einfügt, ist letztlich egal, Hauptsache es klappt.

[Thorsten Otto]

Aber in Fortran habe ich sowieso das Konzept des abstrakten Datensatztrenners. D.h. ich muss das Programm nicht ändern, die Runtime-Bibliothek sorgt dafür, dass ich die für das jeweilige Betriebssystem bzw. Ausgabegerät korrekten Zeichen bekomme.

Ja, aber dort das gleich zu veranstalten wie für MinGW wäre denke ich nicht richtig. Das würde CRLF dann auch in Dateien schreiben, was für eine eigentlich auf unix ausgerichtete Umgebung nicht richtig wäre. Ausserdem funktioniert das dort wohl nur, weil auch auf lowlevel mittels O_TEXT/O_BINARY diese Umwandlung vorgenommen wird, was bei der mintlib nicht der Fall ist. Ich hab es auf  jeden Fall erstmal so gelassen, will ich noch nicht ganz überblicke was das sonst noch für Konsequenzen hätte.

Mit dem Fehler bin ich ein bisschen weiter gekommen: die Programme funktionieren, wenn ich beim strippen der Fortran-Bibliothek -x weglasse. Warum das so ist, ist mir allerdings schleierhaft, ebenso warum das nur bei 64bit-cross-compilern ein Problem ist.

[czietz]

Ich bin auch etwas weitergekommen:

In C funktioniert, das hinzufügen eines CR, weil ein Aufruf wie...
printf("The answer to life, the universe and everything is %d\n", 42);
... durch __stdio_text_write() geschickt wird, was das CR hinzufügt.

Die Fortran-Laufzeitbibliothek hingegen kippt den String (da HAVE_CRLF nicht definiert ist) nur mit einem LF versehen in write() ein. Das hätte zwar grundsätzlich die Möglichkeit, ein CR hinzuzufügen. Es scheitert aber daran, dass die Datei nicht mit (flags & RAW) geöffnet ist. Das ist offenbar ein bekannter Bug in MiNTLib: "BUG: under TOS, CRMOD doesn't work unless RAW is on or SIGINT is being caught".

Macht halt Fortran-Programme kaputt. 

[Thorsten Otto]

Macht halt Fortran-Programme kaputt. 

Ja, müsste man sich wohl nochmal genauer anschauen. Betrifft ja alle Programme, die über write() as ausgeben. Wobei mir der code sowieso suspekt vorkommt: wenn RAW gesetzt ist, wird CRMOD berücksichtigt, sonst nicht? Würde eigentlich erwarten, daß es genau andersrum ist.

BTW.: denke habe das ursprüngliche Problem in strip gefunden: bei -x werden auch die __CTOR_LIST__/__DTOR_LIST__ (für constructors/destructors) entfernt. Muss ich noch verifizieren, und noch rausfinden warum das nur bei der 64bit-version passiert, aber in der fortran-bibliothek werden dort u.a. auch die units initialisiert, denke mal das dürfte die Ursache für die Probleme sein.

[Thorsten Otto]

Update: problem in binutils behoben (Archive auf der Download-Seite sind auch aktuaiisiert). Es war nicht unbedingt ein bug (das Symbol war lokal, und wurde gelöscht weil ich in dem Kommando -x verwendet habe), habe die binutils aber trotzdem geändert, weil es eigentlich eine nicht-so-gute Idee ist die zu löschen. Die 32-bit und 64-bit Versionen haben sich da übrigens gleich verhalten, warum die 32bit Version trotzdem funktioniert hat, ist mir eigentlich nicht so ganz klar, aber seis drum

Wers testen möchte, auf http://tho-otto.de/crossmint.php sind jetzt für alle Systeme auch Fortran-Compiler vorhanden (als extra-Archiv). Und mit alle meine ich: auch native für MiNT.

Das oben beschriebene Phänomen mit Linefeed ist noch nicht behoben, tritt aber nur unter TOS auf .

[czietz]

Sorry, falscher Thread!