Software > Coding

gcc, GEMDOS Super und Stackzerstörung

<< < (8/13) > >>

czietz:

--- Zitat von: ari.tao am Di 16.08.2016, 16:34:31 ---Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):

--- Ende Zitat ---

Danke. Wenn ich das richtig verstehe -- da bin ich mir nicht sicher, baut dieser Code darauf auf, dass in TDI Modula-2 offenbar auf Parameter und Rückgabewerte über A6 zugegriffen werden kann und er vertraut darauf, dass dieses Adressregister vom XBIOS-Aufruf nicht überschrieben wird.

Das ist nach C nicht wirklich umsetzbar. Je nach Aufrufkonvention landen die Parameter dort entweder auf dem Stack oder in den Registern D0 - Dx. Es ist nirgendwo dokumentiert, wie Stack und Register aussehen, wenn das XBIOS die eigene Funktion im Supervisor-Modus aufruft.

Und selbst wenn man eine Lösung konstruieren würde, die funktioniert, ist dann nicht gesagt, dass sie das mit jeder TOS-Version (oder EmuTOS oder...) auch tut.


--- Zitat ---Es liegt mir fern, den CoreMark in Zweifel zu ziehen. Aber der dient doch in erster Linie dazu, Prozessoren zu vergleichen? Beim RAM-Test spielt der Bus eine wesentliche Rolle.
Ist der CoreMark (nomen est omen?) dafür denn auch zuständig?

--- Ende Zitat ---

Das EEMBC schreibt: "[Coremark]  will be useful for testing a processor’s pipeline operation, memory (or cache if any) access, and handling of integer operations." Aber letztlich will ich ja keine Maschinen vergleichen, sondern Compiler. RAM und Integerperformance der CPU sind gleich, nur was der Compiler aus dem Code macht nicht. Und da bleibe ich dabei, dass mit YAART wohl eine Schwachstelle im gcc-Optimierer triggere.


--- Zitat ---Übrigens wird im BegleitText zum Dhrystone die von Dir @czietz angesprochene Optimierungs-Problematik durchaus berücksichtigt.

--- Ende Zitat ---

Das Problem ist, dass seit der Veröffentlichung von Dhrystone vor 30(?) Jahren die Optimierer durchaus "schlauer" geworden sind und Dinge vorberechnen, die die Macher nicht berücksichtigt haben. Der Dhrystone-Code in C, den ich kenne, ist so verworren, dass ich dafür aber kein konkretes Beispiel liefern kann.


--- Zitat ---@czietz , wo bitte genau finde ich im Hatari-Universum das Stückchen Code, das für die ´Zyklen´ zuständig ist?

--- Ende Zitat ---

Was meinst Du damit? Wo das im Quelltext von Hatari ist? Das weiß ich nicht, die hatari-devel-Mailingliste aber wahrscheinlich schon. Es wird vermutlich kein "Stückchen" Code geben. Die taktzyklusgenau simulierte CPU weiß natürlich, wie viele Zyklen sie für jede Instruktion gebraucht hat (auch die Zugriffsgeschwindigkeiten auf RAM, ROM etc. werden von Hatari für den ST korrekt simuliert), aber wie das an den Profiler herausgegeben wird, keine Ahnung.

ari.tao:

--- Zitat ---  ...dass in TDI Modula-2 offenbar auf Parameter und Rückgabewerte über A6 zugegriffen werden kann und er vertraut darauf, dass dieses Adressregister vom XBIOS-Aufruf nicht überschrieben wird. 
--- Ende Zitat ---
Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

--- Zitat --- Das ist nach C nicht wirklich umsetzbar. Je nach Aufrufkonvention landen die Parameter dort entweder auf dem Stack oder in den Registern D0 - Dx. 
--- Ende Zitat ---
Doch, doch. Das ist für M2- und andere Compiler auch nicht viel anders. TDI-M2 packt alle Parameter grundsätzlich auf den Stack, mit wenigen Ausnahmen (zB. die in TDI eingebaute IEEE-Arithmetik). Siehe Anhänge.

--- Zitat --- Es ist nirgendwo dokumentiert, wie Stack und Register aussehen, wenn das XBIOS die eigene Funktion im Supervisor-Modus aufruft.   
--- Ende Zitat ---
Rtfm zu XBIOS_38.
Vielleicht kennt ja jmd. den Zeitschriften-Artikel, der mir verloren ging? (Muß _vor_ 1998 gewesen sein). Möglicherweise war der sogar mit C formuliert?

--- Zitat --- nicht gesagt, dass sie das mit jeder TOS-Version (oder EmuTOS oder...) auch tut. 
--- Ende Zitat ---
Alle mir bekannten TOS-Versionen halten sich an das dargelegte, und alle Emulatoren sollten das gefälligst auch tun. (Das ProfiBuch nennt zwar an der zitierten Stelle nicht explizit die Quelle, aber ich denke mal, daß die richtig aus der Atari-Doku abgeschrieben haben.) Aber ich habe das fertig kompilierte Sup_Demo.TOS ja gepostet, kannste also selbst ausprobieren.

--- Zitat --- ...Schwachstelle im gcc-Optimierer triggere.
--- Ende Zitat ---
Dazu habe ich meine Meinung ja deutlich kundgetan. Noch weiter lehne ich mich nicht aus dem Fenster.

--- Zitat ---Der Dhrystone-Code in C, den ich kenne,...   
--- Ende Zitat ---
In der ST-C.-PD338 gab es eine C-Portierung des Dhry; ich habe da nie hineingeschaut. Der Dhrystone wurde mW. ursprünglich in ADA geschrieben, die Portierungen nach PASCAL und MODULA waren wohl mehr oder weniger ´straightforward´. Meine M2-Versionen habe ich ja gepostet. Im .MOD sind auch meine Test-Ergebnisse notiert.

--- Zitat ---
--- Zitat --- @czietz , wo bitte genau finde ich im Hatari-Universum das Stückchen Code, das für die ´Zyklen´ zuständig ist?
--- Ende Zitat ---
Was meinst Du damit? Wo das im Quelltext von Hatari ist? 
--- Ende Zitat ---
Ja, exakt.

--- Zitat --- Die taktzyklusgenau simulierte CPU ...
--- Ende Zitat ---
Das halte ich entweder für ein Wunder, oder aber, wahrscheinlicher, für Blendwerk & Zauberei. Zum Taktzählen habe ich mich oben in Posting #18 ja schon geäußert. Niemand kann imho vorhersagen, wann ein (im Kontext eingebettetes) Stück Code im Proz.-Cache landet und wann nicht, zumal der Cache des 68030 ja nicht gerade riesig ist. Vielleicht ist genau das der Grund für die Unterschiede bei Deinem YAART (und damit wäre der gcc-Optimierer vielleicht ganz unschuldig, es könnte auch eine Frage der eingebundenen Libs sein).

mfro:

--- Zitat von: ari.tao am Do 18.08.2016, 05:56:18 ---
--- Zitat ---  ...dass in TDI Modula-2 offenbar auf Parameter und Rückgabewerte über A6 zugegriffen werden kann und er vertraut darauf, dass dieses Adressregister vom XBIOS-Aufruf nicht überschrieben wird. 
--- Ende Zitat ---
Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

--- Ende Zitat ---

Daß deine Methode bei dir funktioniert, glaub' ich gleich.

Daß sie immer funktionieren muß, sehe ich ganz und gar nicht als garantiert.

Im Profibuch (und anderswo) steht lediglich, welche Register beim XBIOS-Aufruf gerettet und danach wiederhergestellt werden.

Wenn ich richtig verstehe (ist ein bißchen verwirrend, weil man den - offensichtlich von TDI-Modula eingeschobenen - Funktionsprolog LINK a6,xxx nicht sieht), übergibt dein Code auf dem Stack einen Zeiger auf die lokalen Variablen der aufrufenden Prozedur (relativ zu A6, daß wäre bei gcc sehr ähnlich, zumindest wenn man ohne -fomit-frame-pointer compiliert) und läßt die von der im Supervisor-Mode aufgerufenen Funktion befüllen.

Daß der Stack beim Supexec()-Aufruf so aussieht, wie er eben aussieht, wenn das XBIOS den Supervisor-Mode aktiviert hat und deine Routine als Callback aufruft, garantiert niemand (kann ich zumindest in den von dir geposteten Verweisen nicht rauslesen). Noch nicht einmal, daß das überhaupt derselbe Stack ist (der Stackpointer könnte ganz ohne Konflikt mit den zugesicherten Eigenschaften auch ganz woanders hinzeigen).

Es wird lediglich garantiert, daß die genannten Register nach dem Trap wieder genauso aussehen wie vorher. Mein Fazit: kann so funktionieren, muß aber nicht.

czietz:

--- Zitat von: ari.tao am Do 18.08.2016, 05:56:18 ---Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

--- Ende Zitat ---

Dort steht, welche Register vor der Rückkehr aus dem Trap wiederhergestellt werden. Dort steht nicht, welche Register im Trap erhalten bleiben. Und genau im Trap bin ich ja, wenn das XBIOS (Supexec) meine Funktion aufruft. Fakt ist: Keine der von Dir zitierten Stellen sagt etwas zur Belegung der Register, die meine von Supexec aufgerufene Funktion sieht.


--- Zitat ---
--- Zitat --- Es ist nirgendwo dokumentiert, wie Stack und Register aussehen, wenn das XBIOS die eigene Funktion im Supervisor-Modus aufruft.   
--- Ende Zitat ---
Rtfm zu XBIOS_38.

--- Ende Zitat ---

Vielleicht magst Du genauer werden? Fakt ist: Weder im Profibuch noch in Ataris Hitchhiker Guide to the BIOS wird dokumentiert, wie die Registerbelegung ist, wenn Supexec meine Funktion aufruft. Damit darf ich mich nicht darauf verlassen, wo ich den User Stack vorfinde, auf dem meine Parameter wären.

PS: Und @mfro formuliert diesen Punkt noch besser, als ich es könnte.


--- Zitat ---
--- Zitat --- ...Schwachstelle im gcc-Optimierer triggere.
--- Ende Zitat ---
Dazu habe ich meine Meinung ja deutlich kundgetan. Noch weiter lehne ich mich nicht aus dem Fenster.

--- Ende Zitat ---

Fakt ist: YAART und yrt_tim laufen mit gcc langsamer. Das lässt sich durch noch so viel Diskussion nicht wegdiskutieren. Fakt ist auch: Ich habe mir den generierten Assembler-Code angesehen und er ist unbestreitbar ineffizienter als der von Pure C. Meine Erkenntnisse kannst Du weiter oben im Thread bereits nachlesen.


--- Zitat ---
--- Zitat --- Die taktzyklusgenau simulierte CPU ...
--- Ende Zitat ---
Das halte ich entweder für ein Wunder, oder aber, wahrscheinlicher, für Blendwerk & Zauberei. Zum Taktzählen habe ich mich oben in Posting #18 ja schon geäußert. Niemand kann imho vorhersagen, wann ein (im Kontext eingebettetes) Stück Code im Proz.-Cache landet und wann nicht, zumal der Cache des 68030 ja nicht gerade riesig ist.

--- Ende Zitat ---

Ich weiß nicht, warum Du immer wieder mit dem 68030 um die Ecke kommst. YAART ist für STs geschrieben, entsprechend findet das ganze Benchmarking mit einem 68000 statt. Fakt ist: Für einen ST ist Hatari zyklusgenau. Das magst Du bezweifeln, es ist aber so. Übrigens: Wäre das nicht der Fall liefen viele Demos und Spiele nicht in Hatari. Auf der Hatari-devel-Mailingliste beantwortet man sicherlich gerne Deine Zweifel.


--- Zitat ---Vielleicht ist genau das der Grund für die Unterschiede bei Deinem YAART (und damit wäre der gcc-Optimierer vielleicht ganz unschuldig, es könnte auch eine Frage der eingebundenen Libs sein).

--- Ende Zitat ---

Ich schreibe es zum wiederholten Mal: 1. Es geht um einen 68000. 2. Es werden im getesteten Code keine Bibliotheksfunktionen aufgerufen. 3. Der Code ist unwiderlegbar ineffizient, ich habe ihn mir angesehen.

czietz:
PS: Ich habe mir für die in http://forum.atari-home.de/index.php?topic=13075.msg209397#msg209397 gepostete Schleife den Assembler-Quelltext vorgenommen und mit YACHT http://nemesis.hacking-cult.org/MegaDrive/Documentation/Yacht.txt die CPU-Taktzyklen darin gezählt, für einen 68000 natürlich. Man kommt auch bei Handzählung auf dasselbe Verhältnis PureC zu gcc. Damit ist für mich noch einmal gezeigt, dass Hataris Profiler kein "Blendwerk & Zauberei" ist sondern vollkommen richtig liegt. Wo ist der Gegenbeweis?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete