Autor Thema: gcc, GEMDOS Super und Stackzerstörung  (Gelesen 26462 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #20 am: So 14.08.2016, 10:56:16 »
ad @mfro :
Könnte sich Deine Biene, bitte bitte, auch mal setzen? Das Viech ist derart lästig, daß ich mich davon immer in den H... gestochen fühle  :'(

Nee, tut mir außerordentlich leid, das kann die nicht (ist ja schließlich eine BusyBee). Aber wenn's dir derart auf die Nerven geht:

about: config

image.animation_mode: once

Dann fliegt sie beim Laden der Seite nur noch einmal im Kringel rum und setzt sich dann hin. Zumindest, wenn Du Firefox benutzt.
And remember: Beethoven wrote his first symphony in C

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Benchmarking
« Antwort #21 am: So 14.08.2016, 14:28:14 »
Die Performance kann man afaik immer nur für das Gesamt-System vergleichen, also die Kombi Maschine + Compiler. Das macht man (auf Ataris) mit dem Dhrystone-Test. Die ´ticks´ alleine dürften ziemlich irreführend sein!

Nochwas zum Thema Benchmarks: Soweit ich weiß, krankt der Dhrystone-Test daran, dass es einige Dinge darin gibt, die ein "schlauer" Compiler einfach vorberechnen kann. Somit wäre der gcc hier vermutlich einem Pure C von vor 25 Jahren überlegen.

Nur finde ich genau das dann irreführend. Was nützt es mir, wenn gcc für einen synthetischen Benchmark tollen Code erzeugt, meine tatsächliche Anwendung aber mit gcc compiliert langsamer wird? YAART (und der gepostete Auszug yrt_tim.c) sind ja keine Benchmarks, sondern eine konkrete Anwendung, die natürlich so schnell wie möglich auf dem ST laufen soll.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #22 am: So 14.08.2016, 15:33:16 »
Ja. Also einfach den Test laufen lassen mit der Stoppuhr in der Hand, anstatt ticks zählen. Ach, ich sehe gerade, das hast Du ja praktisch getan mit dem HZ200.
Wo hast Du denn von Zyklen geschrieben? Ich habe immer nur ´ticks´ gelesen. Für die 5msec-Intervalle des HZ200 ist mW. der Ausdruck ´jiffies´ gebräuchlich.
Das M2-Bsp. werde ich bei nächster Gelegenheit mal raussuchen.

PS: Ich glaube nicht, daß ausgerechnet der gcc aus der VW-Kategorie stammt.
« Letzte Änderung: So 14.08.2016, 15:49:40 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: Benchmarking
« Antwort #23 am: So 14.08.2016, 15:51:50 »
Ja. Also einfach den Test laufen lassen mit der Stoppuhr in der Hand, anstatt ticks zählen.

Die "ticks" sind wie eine Stoppuhr! Das kommt auf gleiche hinaus, wie ich in meinem anderen Posting erklärt habe: http://forum.atari-home.de/index.php?topic=13075.msg209672#msg209672.

EDIT: "Zyklen", gemessen mit Hatari, kommen z.B. in folgendem Post vor: http://forum.atari-home.de/index.php?topic=13075.msg209381#msg209381

Zitat
PS: Ich glaube nicht, daß ausgerechnet der gcc aus der VW-Kategorie stammt.

Das hat nichts mit Mogeln seitens des gcc zu tun, wenn er Dinge vorausberechnet, die schon zur Compile-Zeit bekannt sind! Es verfälscht nur Benchmarks, die das nicht bedenken. Ein kleines Beispiel: Der Optimierer von gcc wird...
if (strlen("Hello") == 42) {
printf("ERROR!");
}
... komplett weg-optimieren, da er das Resultat von strlen schon kennt. Versuchte man, mit solchem Code die String-Performance zu benchmarken, fiele man ganz schön auf die Nase.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #24 am: So 14.08.2016, 16:11:43 »
Das sehe ich genau umgekehrt: Wenn der Compiler so schlau ist - hat er dann nicht zu Recht die Nase vorn?!
Ach, jetzt sind wir ein wenig um die Wette gelaufen, die ´Zyklen´ hatte ich inzwischen schon gefunden. Wie (& wo) hast Du die gemessen? Hatari kenne ich nicht.
« Letzte Änderung: So 14.08.2016, 16:14:51 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: Benchmarking
« Antwort #25 am: So 14.08.2016, 16:17:32 »
Oder ein realistischeres Beispiel: Nehmen wir an, jemand wollte die Integer-Performance einer CPU (Additionen, Multiplikationen, Shifts) mittels folgendem Benchmark testen:

#include <stdio.h>
#include <string.h>
#include <stdint.h>

static uint32_t int_performance(uint32_t input) {

input <<=  7;
input += 255;
input *= 3;
input -= 11;

return input;
}

int main(void) {

int loop;
uint32_t res;

for (loop=0; loop<50000; loop++) {
res = int_performance(42);
if (res != 16882) {
printf("Error\r\n");
}

res = int_performance(111);
if (res != 43378) {
printf("Error\r\n");
}
}

return 0;
}

gcc (m68k-atari-mint-gcc, version 4.6.4) optimiert ab -O2 die komplette for-Schleife(!) weg, sodass der Benchmark nur noch aus return 0; besteht.

Deshalb bevorzuge ich echte Applikationen als Benchmark. Ich habe schon zu viele Tests wie oben gesehen, die nicht berücksichtigen, wie gut moderne Optimierer in manchen Fällen sind.

Das sehe ich genau umgekehrt: Wenn der Compiler so schlau ist - hat er dann nicht zu Recht die Nase vorn?!

Wenn sich das auf die reale Performance niederschlägt, dann ja. Dummerweise sind in manchen Benchmarks aber viele Dinge vorberechnbar (s. oben), in realen Anwendungen hingegen nicht. Fakt ist: Selbst mit -O3 (oder -Os) läuft mein RAM-Test YAART schneller, wenn ich ihn mit Pure C compiliere.

Zitat
Ach, jetzt sind wir ein wenig um die Wette gelaufen, die ´Zyklen´ hatte ich inzwischen schon gefunden. Wie (& wo) hast Du die gemessen?

Schrieb ich doch: Hatari-Profiler: https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Profiling


Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #26 am: So 14.08.2016, 16:56:17 »
Danke @czietz , für den Link. Puh, das ist ja ein Universum! Das ist etwas für lange Winterabende... Jetzt mach´ ich erst mal Pause und geh´ in die Sonne.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #27 am: Mo 15.08.2016, 06:49:11 »
Danke, @mfro , für den Hinweis. Ich benutze den Explorer. Da habe ich trotz einiger Suche kein Menue ´config´ gefunden. Das ist jetzt mal ein echter Grund, endlich FireFox zu installieren!
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #28 am: Mo 15.08.2016, 08:14:17 »
... Ich benutze den Explorer...

Da geht so was auch:
http://praxistipps.chip.de/internet-explorer-gif-bilder-deaktivieren_15640

Der Internet-Explorer ist trotzdem nervig.
And remember: Beethoven wrote his first symphony in C

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #29 am: Mo 15.08.2016, 10:14:56 »
Und vor allem gefährlich (Sicherheitslücken!)
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: Benchmarking
« Antwort #30 am: Mo 15.08.2016, 19:52:13 »
Um zu zeigen, dass nicht alles schlecht ist mit dem gcc, habe ich mal den CoreMark [1] compiliert und laufen lassen. Das ist recht moderner CPU-Benchmark, der über die Kommandozeile parametriert wird, damit der Compiler eben nichts vorberechnen kann.

Hier die Resultate -- jeweils auf einem Atari ST mit 8 MHz, oder vielmehr dessen zyklusgenauer Emulation in Steem. Größere Zahl ist hier besser:

CoreMark 1.0 : 0.814332 / PureC 1.1  / STACK
CoreMark 1.0 : 0.363438 / GCC4.6.4 (MiNT 20130415) -O0 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1   / STACK
CoreMark 1.0 : 1.167202 / GCC4.6.4 (MiNT 20130415) -O1 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1   / STACK
CoreMark 1.0 : 1.716738 / GCC4.6.4 (MiNT 20130415) -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1   / STACK
CoreMark 1.0 : 1.722653 / GCC4.6.4 (MiNT 20130415) -O3 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1   / STACK
CoreMark 1.0 : 1.465738 / GCC4.6.4 (MiNT 20130415) -Os -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1   / STACK

Wie man sieht, muss sich hier PureC dem gcc-Optimierer (teilweise deutlich) geschlagen geben. Und gcc verhält sich plausibel, was die Optimierungsstufen angeht: -O3 ist schneller als -O2 ist schneller als -O1.

Mit meinem yrt_tim.c hingegen stelle ich den gcc-Optimierer wohl auf eine (zu harte) Probe...

[1] http://www.eembc.org/coremark/index.php

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #31 am: Mo 15.08.2016, 21:23:36 »
Ahja. Jetzt stimmt mein Weltbild wieder. Danke!
And remember: Beethoven wrote his first symphony in C

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #32 am: Mo 15.08.2016, 21:51:27 »
Sehr beeindruckendes Ergebnis. Da sieht man dann schon, was 20 Jahre Optimierungen im Compiler so bringen können. Würde man jegliche ST-Software damit kompilieren, wäre der ST ja gleich doppelt so schnell, ganz ohne eine Turbokarte einzubauen. Wow!
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #33 am: Di 16.08.2016, 16:34:31 »
... Ich benutze den Explorer...
Da geht so was auch:
http://praxistipps.chip.de/internet-explorer-gif-bilder-deaktivieren_15640
Danke an @mfro . Erstmal hilft die ESC-Taste (aus og. praxistipps).
Kann der Firefox parallel installiert werden, oder muß ich zuerst den Explorer entfernen?
.......

Man kann SuperExec (XBIOS_38) grundsätzlich auch für Prozeduren mit Parametern verwenden. Falls es noch interessiert, kann ich ein Bsp. für M2(TDI) zeigen, mit C kenne ich mich nicht aus. Alles nur eine Frage des Bindings. 
Auch wenn das Problem mittlerweile gelöst ist, würde mich das Beispiel (auch wenn's in Modula 2 ist) interessieren.
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):
(* IMPLEMENTATION *) MODULE SUP_DEMO;
(* ½ 2016 Ari.Tao * 15.08.16  TDI-M2                      .

     Two examples how to use XBIOS_38 (SuperExec) with parameters:
       SupExec (long out par. only)
       PeekL   (long in & long out par.)

*)(*$T-,$S-,$A+ mini *)
IMPORT GT;
FROM SYSTEM
IMPORT ADR,ADDRESS, WORD, SETREG,CODE;

CONST  RTS  = 4E75H;
       UNLK = 4E5EH;
       TRAP = 4E40H;
      XTRAP = TRAP+14; (* XBIOS *)
      PUSHW = 3F3CH;   (* MOVE.W #*,-(A7) ;          Word-Konstante.*)
      PUSHV = 2F2EH;   (* MOVE.L s(A6),-(A7); Long- v VAR-Parameter.*)
       RETL = 2D40H;   (* MOVE.L D0,d(A6) ;          Long-Ergebnis. *)

CONST SUPER = 38; D0 = 0; PM = 8;

TYPE  SuperPar = RECORD Op: CARDINAL; Code: PROC END;
TYPE  HANDLE   = POINTER TO ADDRESS;

(* Beispiel_1: *)

PROCEDURE SuperExec (Code: PROC);
 BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP) END SuperExec;
PROCEDURE   SupExec (Code: PROC): (*D0 via Code:*) LONGINT;
 BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP, RETL,PM+4, UNLK,RTS) END SupExec;

(* Beispiel_2: *)

PROCEDURE peekL; VAR h: HANDLE; p: POINTER TO RECORD q,z: HANDLE END;(*$S-*)
 BEGIN CODE (RETL+14,-4); p := h^+PM; p^.z := p^.q^ END peekL;       (*$S=*)
PROCEDURE PeekL(a: ADDRESS): (*Val:*) ADDRESS;  VAR P: SuperPar;
 BEGIN P.Op := SUPER; P.Code := peekL; CODE (XTRAP, UNLK,RTS) END PeekL;

(* Test: *)

PROCEDURE TestCode; (*$S-*) BEGIN SETREG (D0, 13H) END TestCode; (*$S=*)
CONST MEMTOP = 436H;

BEGIN (* .TOS *)
      GT.wHexL (SupExec (TestCode), 10);
      GT.wHexL (PeekL (MEMTOP),  10);
  END SUP_DEMO .

Hinweise:
   1) Das Phragma $S- unterdrückt den StackTest des TDI-Compilers.
   2) Selbstverständlich sind die Bindings Compiler-abhängig, also nur bedingt portabel.
   3) Die Idee stammt aus einem Zeitschriften-Artikel. Leider ging mir die Quelle verloren.
   4) Das fertig kompilierte Prg. -> Anhang (ziemlich uninteressant, nur zur Vollständigkeit)
.......

Ad Benchmarking:
Zitat
Deshalb bevorzuge ich echte Applikationen als Benchmark. 
Klaro, dacour.
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? Wenn nicht, dann ist
Zitat
Fakt ist: Selbst mit -O3 (oder -Os) läuft mein RAM-Test YAART schneller, wenn ich ihn mit Pure C compiliere. 
überhaupt kein Wunder. Der gcc wurde vermutlich dem CoreMark angepaßt, aber PureC dem Dhrystone oä.
Übrigens wird im BegleitText zum Dhrystone die von Dir @czietz angesprochene Optimierungs-Problematik durchaus berücksichtigt. Deshalb halte ich imho diesen mittelalterlichen Test für unsere OldTimer immer noch für gut geeignet. An ein paar wenigen Dhrystones Unterschied würde ich keine Bewertung festmachen, aber bei einem Faktor von ca. 2 gibt es am Dhrystone wohl nix herumzukritteln. Man kann jedenfalls gut sehen, daß der TT mehr Leistung hat als ein F30 mit 32MHz oder auch die groben Unterschiede in verschiedenen Compiler-Designs oder auch den Einfluß des BusTakts oder auch, wieviel Performance eine höhere Grafik-Auflösung im Falcon kostet; und das ist alles sehr plausibel.
.......

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

Eine jede Wissenschaft hat ein sog. Hauptproblem. Dasjenige der Informatik ist nicht etwa, Information zu erzeugen, sondern, sie (wieder-)zufinden!
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #34 am: Di 16.08.2016, 17:03:16 »
Offtopic, ari.tao schrieb:
Zitat
Kann der Firefox parallel installiert werden, oder muß ich zuerst den Explorer entfernen?
Du musst den Exploder nicht entfernen, kannst du unter Windows nichtmal. Du darfst gerne neben dem Firefox auch noch Chrome, Opera, ... parallel installieren und gleichzeitig starten und mit allen gleichzeitig surfen! Und dann legst du dir einen der neuen Browser als Standard fest und hast in Zukunft Ruhe vor dem IE, wenn du möchtest. Mindestens der Firefox kann auch all deine Lesezeichen usw. vom IE importieren.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: Benchmarking
« Antwort #35 am: Di 16.08.2016, 18:56:07 »
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):

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?

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.

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?

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.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #36 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. 
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. 
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.   
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. 
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.
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,...   
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?
Was meinst Du damit? Wo das im Quelltext von Hatari ist? 
Ja, exakt.
Zitat
Die taktzyklusgenau simulierte CPU ...
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).
« Letzte Änderung: Do 18.08.2016, 06:06:43 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #37 am: Do 18.08.2016, 07:40:42 »
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. 
Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

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.

And remember: Beethoven wrote his first symphony in C

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #38 am: Do 18.08.2016, 07:44:09 »
Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

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.   
Rtfm zu XBIOS_38.

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.
Dazu habe ich meine Meinung ja deutlich kundgetan. Noch weiter lehne ich mich nicht aus dem Fenster.

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

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

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.

Offline czietz

  • Benutzer
  • Beiträge: 3.570
Re: gcc, GEMDOS Super und Stackzerstörung
« Antwort #39 am: Do 18.08.2016, 08:15:23 »
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?