Software > Coding
gcc, GEMDOS Super und Stackzerstörung
mfro:
Ich geb's auf. Mach' wie Du denkst.
ari.tao:
Ich danke Dir, @mfro , für Deinen hartnäckigen Widerstand. Auf diese Weise ist wohl jedem Mitlesenden deutlich geworden, in welchem Dilemma wir stecken, und erst recht diejenigen, die sich um eine Weiterentwicklung bemühen. Ich habe mir das von Dir zitierte MiNT-Binding mit sehr gemischten Gefühlen angesehen... Was immer sich die Entwickler bei dieser Akrobatik gedacht haben - es ist jedenfalls ein (durch die Umkopiererei) sehr ´langsames´ Binding. Das ´schnellste´ Binding, das ich mal sah (wo war denn das bloß? Mac? kann´s nicht wiederfinden), war direkt ´im Compiler eingebaut´ (dh. es genügte das .DEF, der .IMP-Teil entfiel), das war ´am nächsten dran´ am Prozessor. Womit wir noch einmal beim Thema Optimierung wären. Ich kann Euch alle nur warnen, um weniger Prozentchen willen großen Aufwand zu treiben - es lohnt sich nicht, wenn dann nach kurzer Zeit der Fortschritt bei der Hardware nicht nur durch so viele Prozente mehr die Anstrengung obsolet macht, sondern auch noch die Portabilität behindert.
Schade, daß niemand bereit war, meiner Bitte aus Posting #44 nachzukommen und SUP_TEST.TOS mal auf alternativen TOSsen laufen zu lassen; so weiß ich nun immer noch nicht genau, ob ich meine Lib an ca. fünf Stellen ändern sollte, oder ob alles so bleiben kann :-\.
mfro:
--- Zitat von: ari.tao am Di 23.08.2016, 11:18:28 ---... Ich habe mir das von Dir zitierte MiNT-Binding mit sehr gemischten Gefühlen angesehen... Was immer sich die Entwickler bei dieser Akrobatik gedacht haben - es ist jedenfalls ein (durch die Umkopiererei) sehr ´langsames´ Binding...
--- Ende Zitat ---
* was Du dir da angeguckt hast, ist kein "Binding", sondern die Implementierung des Einsprungs in eine Betriebssystemfunktion. Ein Binding ist die Implementierung einer API-Schnittstelle auf der Client- (also der anderen) Seite
* so machen das moderne (richtige) Betriebssysteme eben. Beim Aufruf einer OS-Funktion gibt's ein copy-in (Kopieren der Parameter vom User- in den Kernelspace), entsprechend beim Verlassen ein copy-out (Kopieren der berechneten Rückgabeparameter vom Kernel- in den Userspace). Wenn man Speicherschutz haben will, geht das nicht anders (der Kernel läßt sich nicht einfach von einem dahergelaufenen Userprozess seine Datenbereiche verändern und er wird ebensowenig von x Stellen - sondern an genau einer, der *Schnitt*-Stelle - Daten im Userspace verändern)
* Im Übrigen ist das ja kein "richtiger" OS-Aufruf, sondern ein Workaround für nicht API-konforme Programme (wie deins), damit die trotz "kreativer Überinterpretation" der Dokumentation auch mit MiNT laufen (sorry, aber das konnte ich mir jetzt nicht verkneifen)
ari.tao:
--- Zitat --- ... kein "Binding", sondern die Implementierung des Einsprungs in eine Betriebssystemfunktion.
--- Ende Zitat ---
Danke für die Korrektur. Da habe ich wohl nicht genau genug hingeschaut. Mir ist C bis heute immer noch ein Greuel.
--- Zitat --- ... Speicherschutz ...
--- Ende Zitat ---
Ich hatte MiNT genau ein einziges Mal ohne np am Laufen - und habe das dann wieder bleiben lassen: Zu viel Atari-Software, die damit schlecht klarkommt.
--- Zitat --- ... ein Workaround für nicht API-konforme Programme ...
--- Ende Zitat ---
Wo kein API ausformuliert ist, kann man nicht konform sein. Und im Sinne von 1ST1 , siehe oben, sollte man Kontinuität waren, wenn etwa eins neu formuliert wird. Davon gehe ich nicht ab.
--- Zitat --- ... trotz "kreativer Überinterpretation" der Dokumentation ... (sorry, aber das konnte ich mir jetzt nicht verkneifen)
--- Ende Zitat ---
Ja, tatsächlich, Du kneifst gerne. Und weil ich kein Masochist bin, weise ich das zurück. Wenn Du´s nochmal tust, kriegst Du von mir einen neuen Spitznamen verpaßt! >:D
mfro:
--- Zitat von: czietz am Fr 12.08.2016, 17:49:05 ---Du hast einen schnelleren Rechner als ich ;). Auf einem 1040ST (original mit 8 MHz) bekomme ich:
gcc -O02579 ticksgcc -O11424 ticksgcc -O21155 ticksgcc -O31048 ticksgcc -Os994 ticks (schneller als O3, wie bei Dir)Pure C940 ticks (Gewinner!)
Die -- nicht im Forum gepostete -- Variante mit lokalen statt mit globalen Variablen liefert:
gcc -O02365 ticksgcc -O1779 ticksgcc -O2806 ticks (langsamer als O1!)gcc -O3725 ticksgcc -Os672 ticksPure C672 ticks (gleichauf mit gcc -Os)
--- Zitat ---... da scheint was mit der Optimierung im Argen zu sein ...
--- Ende Zitat ---
Das sehe ich auch so.
--- Ende Zitat ---
Ich hatte heute ein wenig Musse, mit Thorsten Otto's gcc 8.1-Toolchain (@Thorsten Otto an dieser Stelle ein "danke" dafür) rumzuspielen und mich dabei an diesen Thread erinnert.
Siehe da, obwohl sich (wahrscheinlich) kein Entwickler mehr ernsthaft mit dem m68k-Backend beschäftigt, bringen neue Compilerversionen auch für unsere Oldtimer noch die ein oder andere Überraschung mit:
gcc -O2 322 ticks
(wg. Terrasse auf Hatari 2.1 als ST mono 8 MHz; dass das mit rechten Dingen zugeht, habe ich mit dem "alten" Compiler verifiziert - damit komme ich zwar nicht *exakt* auf deine damaligen Werte, aber ziemlich in die Nähe: 724 Ticks).
Der "neue" Compiler erzeugt die inneren Schleifen nur noch aus drei Befehlen:
--- Code: --- 188: 30c1 movew %d1,%a0@+
18a: b1c0 cmpal %d0,%a0
18c: 65fa bcss 188 <movinv+0x2e>
--- Ende Code ---
Das ist zwar offensichtlich ein ziemlich spezieller Anwendungsfall, aber schön zu sehen, dass auch für uns mit neuen Compilern hin und wieder ein Bröckchen abfällt ;)
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln