Autor Thema: EmuTOS selbst compilieren  (Gelesen 7023 mal)

0 Mitglieder und 2 Gäste betrachten dieses Thema.

Offline mfro

  • Benutzer
  • Beiträge: 1.332
Re: EmuTOS selbst compilieren
« Antwort #100 am: So 07.10.2018, 12:12:21 »
Zum Vergleich: Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).

Cygwin, oder?

Die obige Zahl ja. Jetzt mal unter dem Windows Subsystem for Linux und damit quasi nativ: 5 Sekunden für ein EmuTOS 192k. Ich hätte nicht gedacht, dass Cygwin den Prozess so stark verlangsamt.

Das geht (mit 8 Kernen) noch deutlich schneller:

make clean
time make 192 -j
...
m68k-atari-mint-gcc -m68000 -mshort -nostartfiles -nostdlib obj/startup.o obj/lowstram.o obj/memory.o obj/processor.o obj/vectors.o obj/aciavecs.o obj/bios.o og
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001404 MEMBOT=0x0000dd48
./mkrom pad 192k emutos.img etos192us.img
# Padding emutos.img to 192 KB image into etos192us.img
# etos192us.img done (3736 bytes free)
# RAM used: 56648 bytes (4936 bytes more than TOS 1.02)

real 0m1,522s
user 0m7,593s
sys 0m0,640s

1,5 Sekunden. Nicht daß das unbedingt notwendig wäre ;)
And remember: Beethoven wrote his first symphony in C

Offline czietz

  • Benutzer
  • Beiträge: 2.151
Re: EmuTOS selbst compilieren
« Antwort #101 am: So 07.10.2018, 12:47:24 »

Was mich interessieren würde: ob bei nontrivialen Allerweltsaufgaben der gcc-Code tatsächlich schneller auf der Zielhardware (68030/16 …) läuft als PureC.


Dazu habe ich mein Experiment mit CoreMark wiederholt, dieses Mal auf dem TT:

PureC 1.1, Codegenerierung für 68020 und 68881 (FPU) aktiviert: 7,77 Iterationen/Sekunde,
gcc 4.6.4 (von Vincent) -O2 -mcpu=68030: 14,67 Iterationen/Sekunde.

Damit ist der TT etwa 8-9 so schnell wie mein ST: https://forum.atari-home.de/index.php/topic,13075.msg209718.html#msg209718, das Verhältnis zwischen PureC und gcc 4.6.4 bleibt ähnlich.

Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.

Was CoreMark (https://github.com/eembc/coremark) macht, würde ich schon als "nontrivialen Allerweltsaufgaben" bezeichnen. Also Algorithmen, die man auch in Anwendungen finden könnte: Listen abarbeiten, Sortieren, CRCs, State-Machines, Arithmetik...
« Letzte Änderung: So 07.10.2018, 13:23:31 von czietz »

Offline gh-baden

  • Benutzer
  • Beiträge: 1.181
OFF: EmuTOS selbst compilieren
« Antwort #102 am: So 07.10.2018, 13:02:17 »
Das geht (mit 8 Kernen) noch deutlich schneller:

make clean
time make 192 -j
...
m68k-atari-mint-gcc -m68000 -mshort -nostartfiles -nostdlib obj/startup.o obj/lowstram.o obj/memory.o obj/processor.o obj/vectors.o obj/aciavecs.o obj/bios.o og
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001404 MEMBOT=0x0000dd48
./mkrom pad 192k emutos.img etos192us.img
# Padding emutos.img to 192 KB image into etos192us.img
# etos192us.img done (3736 bytes free)
# RAM used: 56648 bytes (4936 bytes more than TOS 1.02)

real 0m1,522s
user 0m7,593s
sys 0m0,640s

1,5 Sekunden. Nicht daß das unbedingt notwendig wäre ;)

Ich habe für das OpenSource-IRC-Server-Daemon-Projekt eines Freundes damals angefangen zu benchen, wie lange das Bauen braucht. Als die Werte unter 1s fielen, hab ich aufgehört, vor vielen Jahren – auf einem Core2Duo mit 2 GHz, also Technik von vor ~14 Jahren.

BTW: Das Bauen auf einem SE/30 mit NetBSD 1.51 dauerte 18 Minuten – wobei etwa 10 Minuten für autoconfig draufgingen. Der SE/30 ist etwa 25%-30% langsamer als ein TT, ein reines 68030/16-System mit eher langsamen RAM.

Wenn ich jetzt noch den Benchmark an sich finden würde … https://ngircd.barton.de/platforms.html
« Letzte Änderung: So 07.10.2018, 22:50:12 von gh-baden »
Wider dem Signaturspam!

Offline gh-baden

  • Benutzer
  • Beiträge: 1.181
Re: EmuTOS selbst compilieren
« Antwort #103 am: So 07.10.2018, 13:05:26 »
Dazu habe ich mein Experiment mit CoreMark wiederholt, dieses Mal auf den TT:

PureC 1.1, Codegenerierung für 68020 und 68881 (FPU) aktiviert: 7,77 Iterationen/Sekunde,
gcc 4.6.4 (von Vincent) -O2 -mcpu=68030: 14,67 Iterationen/Sekunde.

[…]

Was CoreMark (https://github.com/eembc/coremark) macht, würde ich schon als "nontrivialen Allerweltsaufgaben" bezeichnen. Also Algorithmen, die man auch in Anwendungen finden könnte: Listen abarbeiten, Sortieren, CRCs, State-Machines, Arithmetik...

Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.
Wider dem Signaturspam!

Offline czietz

  • Benutzer
  • Beiträge: 2.151
gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #104 am: So 07.10.2018, 13:51:09 »
Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.

gcc 8.2.0 (von Thorsten) -O2 -mcpu=68030: 16,99 Iterationen/Sekunde auf dem TT.

PS: Mit den Linux-Binaries des m68k gcc 8.2.0 bin ich natürlich wieder in das Problem gelaufen, das man eigentlich immer hat, wenn man vorcompilierte Binaries unter Linux bekommt: sie verlangen irgendwelche Bibliotheken in Versionen, die es bei mir (Debian 9) nicht gibt.

EDIT: Zum Vergleich: mein aktuelles Notebook: 30774 Iterationen/Sekunde (ein Kern), 93875 Iterationen/Sekunde (alle vier Kerne). Jeweils gcc 6.3.0 -O2. Kein Wunder, dass das Compileren von EmuTOS auf dem TT soviel länger dauert...
« Letzte Änderung: So 07.10.2018, 14:08:07 von czietz »

Offline mfro

  • Benutzer
  • Beiträge: 1.332
Re: EmuTOS selbst compilieren
« Antwort #105 am: So 07.10.2018, 14:10:53 »
Man hat das Gefühl, das gcc wieder ein wenig zulegt, seit echte Konkurrenz (llvm) heranwächst.

Schön ist, daß auch wir offensichtlich was davon haben, obwohl sicher keiner mehr das m68k-Backend auch nur mit dem A... anguckt.
And remember: Beethoven wrote his first symphony in C

Offline mfro

  • Benutzer
  • Beiträge: 1.332
Re: EmuTOS selbst compilieren
« Antwort #106 am: So 07.10.2018, 14:12:18 »
Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.

Ähem.

https://github.com/mfro0/libcmini
And remember: Beethoven wrote his first symphony in C

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 564
Re: EmuTOS selbst compilieren
« Antwort #107 am: So 07.10.2018, 15:10:58 »
Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.

Das sollte in etwa so gehen
$ mkdir /opt/cross-mint
$ cp -pvr /usr/m68k-atari-mint/. /opt/cross-mint
$ mkdir -p /opt/cross-mint/lib64/gcc
$ cp -pvr /usr/lib64/gcc/m68k-atari-mint /opt/cross-mint/lib64/gcc/
$ cd /opt/cross-mint/bin
$ for i in addr2line ar arconv as c++ cnm cpp csize cstrip flags g++ gcc gcov ld ld.bfd mintbin nm objcopy objdump ranlib readelf size stack strings strip symex gcc-7.3.0 g++-7.3.0 cpp-7.3.0; do sudo rm -f $i; cp -a /usr/bin/m68k-atari-mint-$i .; done
$ ln -sf m68k-atari-mint-gcc-7.3.0 m68k-atari-mint-gcc

Ersetze /usr durch das Verzeichnis wo du das Archiv ausgepackt hast, und /opt/cross-mint durch das wo du es installieren möchtest. Das ganze entweder als root oder durch Einsatz von sudo.

Edit: das mit dem umkopieren ist vermutlich nicht mal notwendig, wenn du die Archive mit
$ cd /opt/cross-mint
$ tar  --strip-components=1 -xf gcc-8.2.0-mint-20180831-bin-linux.tar.xz
$ tar  --strip-components=1 -xf binutils-2.31-mint-20180717-bin-linux.tar.xz
auspackst. Und natürlich müssen die libraries (mintlib etc) dann auch dort installiert werden.
« Letzte Änderung: So 07.10.2018, 15:37:10 von Thorsten Otto »

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 564
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #108 am: So 07.10.2018, 15:25:40 »
PS: Mit den Linux-Binaries des m68k gcc 8.2.0 bin ich natürlich wieder in das Problem gelaufen, das man eigentlich immer hat, wenn man vorcompilierte Binaries unter Linux bekommt: sie verlangen irgendwelche Bibliotheken in Versionen, die es bei mir (Debian 9) nicht gibt.

Das ist ein Dauer-Problem von debian, Auch auf neueren Distributionen sind standardmässig oft ziemlich alte Bibliotheken installiert (u.a. libpng12 von vor ~10 Jahren), Im fall von gcc dürfte es sich vermutlich um mpfr handeln?

Offline czietz

  • Benutzer
  • Beiträge: 2.151
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #109 am: So 07.10.2018, 15:35:23 »
Das ist ein Dauer-Problem von debian, Auch auf neueren Distributionen sind standardmässig oft ziemlich alte Bibliotheken installiert (u.a. libpng12 von vor ~10 Jahren), Im fall von gcc dürfte es sich vermutlich um mpfr handeln?

libisl. Und ich sehe das grundsätzlich eher als Feature in Debian...

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 564
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #110 am: So 07.10.2018, 15:46:49 »
libisl.

Ja, da muss ich mal schauen. Die macht bei mir seit dem letzten Upgrade scheinbar auch Probleme, und gcc lässt sich damit gar nicht mehr übersetzen.

Zitat
Und ich sehe das grundsätzlich eher als Feature in Debian...

Also ich nicht. Ich finde das ziemlich arrogant, die ganze Entwicklng die seitdem da rein gesteckt wurde, einfach zu ignorieren. Das motiviert nicht gerade, überhaupt noch etwas zu entwickeln, wenns sowieso ignoriert wird. Ganz abgesehen davon daß da natürlich auch ne Menge Bugfixes bei sind. Oder möchtest du mit einem Firefox von vor 5 Jahren arbeiten, der Schlupflöcher für Viren hat, die man überall frei erhalten kann?

Offline gh-baden

  • Benutzer
  • Beiträge: 1.181
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #111 am: So 07.10.2018, 16:44:38 »
Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.

Ähem.

https://github.com/mfro0/libcmini

*fp* Da hätte ich mal mich erinnern müssen, dabei hatte ich das „damals“ sogar gleich gecloned.

Danke für den Stubs!
Wider dem Signaturspam!

Offline gh-baden

  • Benutzer
  • Beiträge: 1.181
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #112 am: So 07.10.2018, 16:46:29 »
Man hat das Gefühl, das gcc wieder ein wenig zulegt, seit echte Konkurrenz (llvm) heranwächst.

Schön ist, daß auch wir offensichtlich was davon haben, obwohl sicher keiner mehr das m68k-Backend auch nur mit dem A... anguckt.

Ich denke eher, dass das 68k-Backend „bald“ mal rausfliegt. IIRC haben die Debian/68k-Entwickler immer mal wieder mit Maintainern zu argumentieren, dass da ein echter Bug sei und es ja sinnvoll sei, den zu fixen, auch wenn er nur bei 68k zu Tage tritt.
Wider dem Signaturspam!

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 564
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #113 am: So 07.10.2018, 17:59:32 »
Ich denke eher, dass das 68k-Backend „bald“ mal rausfliegt.

Das wär natürlich übel. Aber ich denke eher nicht, es gibt immer noch reichlich Embedded Devices in denen ein m68k oder ähnliches werkelt.

Offline gh-baden

  • Benutzer
  • Beiträge: 1.181
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #114 am: So 07.10.2018, 19:03:37 »
gcc 8.2.0 (von Thorsten) -O2 -mcpu=68030: 16,99 Iterationen/Sekunde auf dem TT.

Beim stöbern im Umfeld des Themas stieß ich auf godbolt Compiler Explorer. "Live compiliert" im Browser kann man Ergebnisse vergleichen. Leider kein 68k dabei, aber PowerPC, ARM, MIPS und natürlich viel x86-64. Und n verschiedene gcc-Versionen, von 8.2 bis 4.x; auch clang ist zu finden.

Ich kann mit dem Output wenig anfangen, da es bei mir grade so zum 68k-Assembler lesen reicht, aber Mehrsprachler finden ja vielleicht was :-)
Wider dem Signaturspam!

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 564
Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
« Antwort #115 am: So 07.10.2018, 19:26:23 »
Leider kein 68k dabei

Die Jungs die den brown-gcc gestrickt haben, haben auch sowas gebastelt: http://brownbot.mooo.com/

Offline Lukas Frank

  • Benutzer
  • Beiträge: 9.309
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: EmuTOS selbst compilieren
« Antwort #116 am: So 07.10.2018, 21:28:22 »
Das sind die Unterschiede beim Filesystem Cache mit 4MB oder 128MB beim make 192 COUNTRY=de ...

--- Atari TT MiNT (filesystem cache 4096)/GCC 7.3.0 -------
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e7a4
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
./mkrom: emutos.img is too big: 752 extra bytes
make[1]: *** [etos192de.img] Error 1
make: *** [192] Error 2

real    289m10.035s
user    198m2.880s
sys     79m27.875s

--- Atari TT MiNT (filesystem cache 131072)/GCC 7.3.0 -------
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e7a4
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
./mkrom: emutos.img is too big: 752 extra bytes
make[1]: *** [etos192de.img] Error 1
make: *** [192] Error 2

real    225m59.190s
user    185m36.305s
sys     25m27.385s

Offline ari.tao

  • Benutzer
  • Beiträge: 2.229
  • a tha yo ga a nu sha sa nam
Re: EmuTOS selbst compilieren
« Antwort #117 am: Mo 08.10.2018, 04:54:00 »
Ah, warum hast Du nun den GCC 7.3.0 installiert und nicht den 8.2 ?
Mit der Lib von mfro ?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Lukas Frank

  • Benutzer
  • Beiträge: 9.309
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: EmuTOS selbst compilieren
« Antwort #118 am: Mo 08.10.2018, 07:34:30 »
Habe ich da etwas überlesen? Einen 8.2 gibt es doch noch nicht für den Atari ...

Offline ari.tao

  • Benutzer
  • Beiträge: 2.229
  • a tha yo ga a nu sha sa nam
Re: EmuTOS selbst compilieren
« Antwort #119 am: Mo 08.10.2018, 08:12:04 »
Ach so, danke.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.