EmuTOS selbst compilieren

[mfro]

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:

Code: [Auswählen]

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

[czietz]

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

[gh-baden]

Das geht (mit 8 Kernen) noch deutlich schneller:

Code: [Auswählen]

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

[gh-baden]

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.

[czietz]

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

[mfro]

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.

[mfro]

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

[Thorsten Otto]

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

Code: [Auswählen]

$ 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

Code: [Auswählen]

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

[Thorsten Otto]

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?

[czietz]

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

[Thorsten Otto]

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.

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?

[gh-baden]

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!

[gh-baden]

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.

[Thorsten Otto]

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.

[gh-baden]

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 :-)

[Thorsten Otto]

Leider kein 68k dabei

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

[Lukas Frank]

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

[ari.tao]

Ah, warum hast Du nun den GCC 7.3.0 installiert und nicht den 8.2 ?
Mit der Lib von mfro ?

[Lukas Frank]

Habe ich da etwas überlesen? Einen 8.2 gibt es doch noch nicht für den Atari ...

[ari.tao]

Ach so, danke.