/* switch to supervisor mode so we can manipulate memory */
suret = Super(0);
/* Dinge, die nur im Supervisor-Modus möglich sind */
/* [...] */
/* back to user mode */
Super((void *)suret);
void foobar(void) __attribute__ ((optimize ("no-defer-pop")));#ifdef __GNUC__
/* BARRIER2 is here to expand __LINE__. */
#define BARRIER3(x) goto _barrier##x; _barrier##x:
#define BARRIER2(x) BARRIER3(x)
#define BARRIER BARRIER2(__LINE__)
#else
#define BARRIER
#endif
Aber das Experiment ist ohnehin mehr oder weniger beendet, weil gcc (selbst mit -O2) unglaublich ineffizienten Code generiert. Die "Moving Inversions" in YAART brauchen ca. 50%(!) länger als in der mit Pure C compilierten Version. Darin werden keine Bibliotheksfunktionen aufgerufen, es ist also wirklich der generierte Code.
... Geht mit jeder void ...(void) Funktion
Das interessiert mich, kannst Du den Code mal zeigen?
while (p>start_local) {
if ((x = *(--p)) != patt2_local) {
bad = x;
}
*p = patt1_local;
}
Mit -O3 braucht die gepostete Schleife mit gcc nur noch 15% länger als mit Pure C. Immer noch nicht toll.
gcc -O3 hält den Pointer p in zwei Adressregistern vor, einen zum Lesen und Beschreiben der Speicherstelle und einen zum Vergleich mit start. So müssen beide Register in jeder Schleife synchronisiert werden und das kostet unnötig Zeit.
Took 185 Ticks.
Took 204 Ticks.
Took 171 Ticks
| gcc -O0 | 2579 ticks |
| gcc -O1 | 1424 ticks |
| gcc -O2 | 1155 ticks |
| gcc -O3 | 1048 ticks |
| gcc -Os | 994 ticks (schneller als O3, wie bei Dir) |
| Pure C | 940 ticks (Gewinner!) |
| gcc -O0 | 2365 ticks |
| gcc -O1 | 779 ticks |
| gcc -O2 | 806 ticks (langsamer als O1!) |
| gcc -O3 | 725 ticks |
| gcc -Os | 672 ticks |
| Pure C | 672 ticks (gleichauf mit gcc -Os) |
... da scheint was mit der Optimierung im Argen zu sein ...
Du hast einen schnelleren Rechner als ich ;). Auf einem 1040ST (original mit 8 MHz)...
SuperToUser() dürfte tatsächlich eine Lösung sein. Supexec() ist hier nicht so toll, weil ich -- anders im Beispiel mit foobar() -- schon Parameter an die Funktion übergeben will, am liebsten ohne globale Variablen dafür zu verwenden.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. Übrigens kann man auch mittels GEMDOS_32 ein SuperExec ´zusammenbinden´.
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!Du hast einen schnelleren Rechner als ich ;). Auf einem 1040ST (original mit 8 MHz)...... einen (fast) originalen TT.
Lustigerweise wird's da auch mit -O3 -mcpu=68030 -mtune=68030 nur unwesentlich schneller, das mit Abstand beste Ergebnis liefert auch da der 68000 code mit -Os ...
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.
ad offTopic:
Mit großem Interesse verfolge ich, wie Eure C-Compiler ´ticken´ . Weiß jmd., wie gcc die genannten ´ticks´ berechnet? Würde mich stark interessieren!
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!
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 :'(
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!
Ja. Also einfach den Test laufen lassen mit der Stoppuhr in der Hand, anstatt ticks zählen.
PS: Ich glaube nicht, daß ausgerechnet der gcc aus der VW-Kategorie stammt.
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.
#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;
}
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?
... Ich benutze den Explorer...
Danke an @mfro . Erstmal hilft die ESC-Taste (aus og. praxistipps).... Ich benutze den Explorer...Da geht so was auch:
http://praxistipps.chip.de/internet-explorer-gif-bilder-deaktivieren_15640
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):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.
(* 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:Deshalb bevorzuge ich echte Applikationen als Benchmark.Klaro, dacour.
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ä.
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.
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):
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?
Übrigens wird im BegleitText zum Dhrystone die von Dir @czietz angesprochene Optimierungs-Problematik durchaus berücksichtigt.
@czietz , wo bitte genau finde ich im Hatari-Universum das Stückchen Code, das für die ´Zyklen´ zuständig ist?
...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.
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.
Es ist nirgendwo dokumentiert, wie Stack und Register aussehen, wenn das XBIOS die eigene Funktion im Supervisor-Modus aufruft.Rtfm zu XBIOS_38.
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.
...Schwachstelle im gcc-Optimierer triggere.Dazu habe ich meine Meinung ja deutlich kundgetan. Noch weiter lehne ich mich nicht aus dem Fenster.
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.
Ja, exakt.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?
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).
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.
Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.
ZitatEs ist nirgendwo dokumentiert, wie Stack und Register aussehen, wenn das XBIOS die eigene Funktion im Supervisor-Modus aufruft.Rtfm zu XBIOS_38.
Zitat...Schwachstelle im gcc-Optimierer triggere.Dazu habe ich meine Meinung ja deutlich kundgetan. Noch weiter lehne ich mich nicht aus dem Fenster.
ZitatDie 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).
Daß deine Methode bei dir funktioniert, glaub' ich gleich.Noch einmal: Das ist nicht _meine_ Methode. Ich habe sie auch bloß (dankbar) gelernt. Inzwischen habe ich die Literaturangabe wiedergefunden: ST-C. 12/90 S.79 (aber leider habe ich momentan keinen Zugang dazu).
Daß sie immer funktionieren muß, sehe ich ganz und gar nicht als garantiert.Da musse ma gaanz, gaanz schaaf hingucken, dann wird die nackerte Maya schamrot und verschwindet >:D !
Im Profibuch (und anderswo) steht lediglich, welche Register beim XBIOS-Aufruf gerettet und danach wiederhergestellt werden.Nee. Da steht bloß, daß sie _gerettet_ werden. Vermutlich geht es um ihre Seelen >:D .
... weil man den - offensichtlich von TDI-Modula eingeschobenen - Funktionsprolog LINK a6,xxx nicht sieht ...Eben weil ich solch ein Argument vorhersah, habe ich das Disassembling gepostet. Seufz.
übergibt dein Code auf dem Stack ... die lokalen Variablen der aufrufenden Prozedur ... und läßt die von der im Supervisor-Mode aufgerufenen Funktion befüllen.Das hast Du fast richtig gesehen. Alle Parameter _und_ alle lokalen Variablen liegen auf dem Stack! Das ist der ganze Trick.
... zugesicherten Eigenschaften ...Was soll diese jur. Formulierung? Bin ich etwa ein Händler? Ich habe nix ´zugesichert´!
Daß der Stack beim Supexec()-Aufruf so aussieht, wie er eben aussieht, wenn das XBIOS den Supervisor-Mode aktiviert hat und deine Routine ...Ganz ohne Garantie: Es ist so und es bleibt so ;) .
... als Callback aufruft, ...Dieser Ausdruck bezeichnet afaik eine völlig andere Mimik. Auf Deutsch: Das ist kein CallBack (wie zB. wenn Du Dich in SystemVektoren einklinkst).
... daß das überhaupt derselbe Stack ist ...Eben doch. Nirgends in der Beschreibung von XBIOS_38 steht, daß der Stack gewechselt wird! (Und, aber das ist wie oben bemerkt eine ganz andere Diskussion, wenn es etwa der Client tut, ist der auch selber dafür verantwortlich!)
... Fazit: ...Mein Fazit: Tief durchatmen. Ich sehe mich schon wieder gezwungen, alles bis zur letzten Schraube auszubuchstabieren, was doch offensichtlich vor Augen liegt.
Nee, steht dort nicht, siehe oben.
Zitat von: ari.tao am ...ZitatDarauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.Dort steht, welche Register vor der Rückkehr aus dem Trap wiederhergestellt werden.
... welche Register im Trap erhalten bleiben ...Wie schon angedeutet: Alle, die der Client unberührt läßt bzw. nach eig. Gebrauch wieder restauriert. (Andere XBIOS-Funktionen setzen uU. D0; hier aber darf es der Client!)
Keine der von Dir zitierten Stellen sagt etwas zur Belegung der Register, die meine von Supexec aufgerufene Funktion sieht.Ist ja, wie dargelegt, auch völlig unnötig. Im Super(Visor)Mode kann ja kein anderes UserPrg. dazwischenspucken, und wenn Du nicht willst, daß der Client bei seiner Arbeit vom TOS unterbrochen wird, ... Alles Fragen zu og. Thema "Was darf/muß der Client?" - Und das ist alles auch relevant beim Aufruf von SupExec _ohne_ Parameter. Wenn ich dazu auch noch vortragen muß, dann verlange ich Honorar :P ).
Vielleicht magst Du genauer werden? Fakt ist: Weder im Profibuch noch in Ataris Hitchhiker Guide to the BIOS wird dokumentiert, wie die Registerbelegung ist,...War das nun genau genug? Fakt ist, daß die Doku dazu gar nix sagen muß, weil die Registerbelegung überhaupt nicht tangiert ist. Die Programmierung läuft genauso wie sonst auch. (Natürlich unter Beachtung der Regeln für den SuperMode sowie TOS-Calls).
Ich schreibe es zum wiederholten Mal: 1. Es geht um einen 68000.Soweit ich weiß, geht es um das Testen den ST-RAMS. Daß Du nur das am 68000er meinst, habe ich so nicht verstanden. Und ich habe Dir ja auch nicht verheimlicht, daß ich damit das ST-RAM im F30 und im TT getestet habe.
Für einen ST ist Hatari zyklusgenau. Das magst Du bezweifeln, es ist aber so.Du meinst: für einen 68000er. Das habe ich doch gar nicht bezweifelt.
3. Der Code ist unwiderlegbar ineffizient, ich habe ihn mir angesehen.Das nun ist ein wirklich durchschlagendes Argument ;) .
Für einen ST ist Hatari zyklusgenau.Du meinst sicherlich: Für einen 68000er... (und nicht etwa eine PAK oder so).
in der STC 12/90 habe ich nichts entsprechendes gefundenSteht, wie er schrieb, ab Seite 79.
Folgt leider (genau wie dein Code auch) der auf dem ST sehr verbreiteten Attitüde "wenn's tut, ist's richtig, egal was in der Dokumentation steht"Gegen diesen Anwurf möchte ich mich strikt verwahren. Ich folge der vorh. Doku. ProfiBuch(10) S.36 sagt deutlich: "BIOS & XBIOS nehmen ihre Parameter auf dem Stack entgegen". In der Beschreibung zu XBIOS_38 steht nix gegenteiliges.
Sehr bedauerlich, daß das STC-Archiv da offenbar eine Lücke hat.in der STC 12/90 habe ich nichts entsprechendes gefundenSteht, wie er schrieb, ab Seite 79.
und bis TOS 1.04 so ist. Womit schon fraglich ist ob es mit EmuTOS geht.Bis TOS 4.04 funzt es jedenfalls. Bevor wir da weiter im luftleeren Raum diskutieren: Kann vielleichtl jemand SUP_TEST.TOS einfach mal unter EMUTOS, HATARI, MILAN , FIREBEE oder was auch immer laufen lassen und die Ergebnisse mitteilen? Auch wenn ich überzeugt bin, daß es überall laufen müßte, hätte ich doch gern mal den Praxis-Test.
Im übrigen geht die Diskussion jetzt wohl darum, ob man tun darf, was nicht verboten ist, oder nur das, was explizit erlaubt wurde. Im letzteren Fall dürfte man XBIOS_38 wohl gar nicht benutzen...Die Bemerkung verstehe ich nicht. Supexec() ist offiziell von Atari dokumentiert (Originaltext s.u.). Bloß deine Art der Anwendung eben nicht.
Man lese das Vorwort im ProfiBuch(10) S.2 .
Folgt leider (genau wie dein Code auch) der auf dem ST sehr verbreiteten Attitüde "wenn's tut, ist's richtig, egal was in der Dokumentation steht"Gegen diesen Anwurf möchte ich mich strikt verwahren. Ich folge der vorh. Doku. ProfiBuch(10) S.36 sagt deutlich: "BIOS & XBIOS nehmen ihre Parameter auf dem Stack entgegen". In der Beschreibung zu XBIOS_38 steht nix gegenteiliges.
(38)
supexec
VOID supexec(LONG codeptr);
codeptr points to a piece of code, ending in an RTS, that is executed in supervisor mode. The code cannot perform BIOS or GEMDOS calls. This function is meant to allow programs to hack hardware and protected locations without having to fiddle with GEMDOS get/set supervisor mode call.
Die Bemerkung verstehe ich nicht.Dann will ich das noch mal anders (und konkreter) formulieren:
Soweit so gut.Nein, gar nicht gut. Der Nachsatz
... egal was in der Dokumentation steht ...sowie die nachfolgenden Zeilen stellen mich in eine Ecke mit Pfuschern, Freibeutern und anderen Halunken, die Atari geschadet haben.
Die originale Atari-Dokumentation ...Kannst Du bitte mal genauer zitieren? Das, was Du da gepostet hast über SupExec, scheint mir entweder veraltet oder falsch oder falsch zitiert zu sein. Das ProfiBuch (10) (ich gehe mal davon aus, daß das jeder hat und erspare mir die Abschreiberei) lautet jedenfalls anders. Und das Atari-Compendium, Part_1, p. 4.103 auch. (Ibs. LONG statt VOID!)
...im MiNT-Kernel nachgeschaut...Wo genau bitte?!
...auch in MiNT undokumentiert ...Die MiNT-Quellen sind doch offen, hast Du ja selber grad gesagt, daß Du ´reingeschaut hast! Das _ist_ doch die Doku, was willst Du noch mehr?!
move.l 4(A7), A0
jmp (A0)
Man sieht, daß mit dem gleichen Stack, von dem der Parameter (im ProfiBuch codeptr genannt) geholt wird, direkt in den Client gesprungen wird.
Ist dies nun endlich überzeugend?
Zitat...im MiNT-Kernel nachgeschaut...Wo genau bitte?!
...Ersteres _darf_ man nicht nur deswegen nicht annehmen, weil es nicht dokumentiert ist, sondern sogar _weil_ es dokumentiert ist. Zwar nicht von Atari (die haben nur dokumentiert, daß ein mc68000 drin ist, außen auf der Schachtel) aber von Motorola. Der Prozessor wurde (in bester Absicht und aus gutem Grund) so gebaut, daß er bei einem Trap in den Supervisor Mode schaltet und ab da das Betriebssystem bis zum abschließenden RTE seinen sorgfältig gehüteten eigenen Supervisor-Stack nutzt, um sich nicht auf "schlampige" (oder sogar bösartige) User-Mode Programme (mit möglicherweise verhunztem Stack) verlassen zu müssen.
Deine Argumentation:
Daß der Stack bei XBIOS_38 im Trap erhalten bleibt, darf man nicht
annehmen, weil das nicht dokumentiert ist.
...
Meine Argumentation:
Würde der Stack bei XBIOS_38 im Trap gewechselt, so müßte das
in der Doku stehen (ähnlich wie bei GEMDOS_32). Da in der Doku
nichts dergleichen steht, _muß_ man annehmen, daß der Stack im
Trap erhalten bleibt.
Welche Argumentation die richtige ist, werde ich mit wiedergefundener Doku weiter unten beweisen.
Die MiNT-Quellen sind doch offen, hast Du ja selber grad gesagt, daß Du ´reingeschaut hast! Das _ist_ doch die Doku, was willst Du noch mehr?!Hier zeigt sich m.E. (d)ein grundsätzliches Mißverständnis. Wenn der Quellcode (oder auch das Disassembly) die Dokumentation wäre, könnte man ja nicht einen einzigen Buchstaben mehr dran ändern (es könnte sich ja jemand auf genau den verlassen haben).
... Insbesondere braucht diese Schleife mit gcc ca. 40%(!) länger als mit Pure C.Code: [Auswählen]while (p>start_local) {
if ((x = *(--p)) != patt2_local) {
bad = x;
}
*p = patt1_local;
}
Ich hätte ja gedacht, dass ein moderner Compiler gegen einen aus dem vergangenen Jahrtausend meilenweit überlegen ist. Wohl falsch gedacht...
gcc -O3 hält den Pointer p in zwei Adressregistern vor, einen zum Lesen und Beschreiben der Speicherstelle und einen zum Vergleich mit start.
... das hätte ja eine dokumentierte Inkompatibilität bedeutet ...
Haltet euch einfach an das was im Profibuch steht.Auch das Profibuch ist nicht an allen Stellen richtig. Es gibt von Julian F. Reschke ein Datei mit Korrekturen und Ergänzung zur 10. und 11. Auflage. Rainer Seitel hat auch soetwas erstellt.
... bleibe daher für die entsprechende Stelle in YAART bei Super() ...Das ist völlig legitim @czietz , niemand zwingt Dich (und ich schon gar nicht) 8)
..., sondern sogar _weil_ es dokumentiert ist. Zwar nicht von Atari ..... aber von Motorola.Nee. Das ist ja Dein Fehler, @mfro , daß Du hier die Doku über die Prozessor-Familie zu Hilfe nimmst. Wenn das wahr wäre, dann könnte/dürfte das XBIOS ja nie auf einen anderen Prozessor portiert werden... Ich bin ganz bewußt nicht auf dein Argument vom doppelten Stackwechsel beim TRAPping eingestiegen (Glaubst Du etwa, ich wüßte nicht, wie TRAP funzt?!), sondern verlasse mich in meiner Argumentation nur auf die Atari-Doku.
Wenn der Quellcode ... die Dokumentation wäre ...Wenn nix anderes da ist, dann haben wir eben nur das! Dein Argument, ich würde interpretieren, kehrt sich gegen Dich selbst!
Sowas muss sich unter gleicher Funktionsnummer gleich verhalten, egal unter welcher TOS-Version.Das, @1ST1 , ist genau auch meine Meinung!
Auch das Profibuch ist nicht an allen Stellen richtig. Es gibt ... Korrekturen ...Stimmt. Ich habe drei verschiedene KorrekturDateien. Und dennoch gibt´s weitere Fehler. Ich habe oben in Posting #40 dezent auf einen hingewiesen, ausgerechnet in SupExec:
Andere XBIOS-Funktionen setzen uU. D0; hier aber darf es der Client!Das widerspricht doch dem, was ProfiBuch & Compendium behaupten?
... 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...
... kein "Binding", sondern die Implementierung des Einsprungs in eine Betriebssystemfunktion.Danke für die Korrektur. Da habe ich wohl nicht genau genug hingeschaut. Mir ist C bis heute immer noch ein Greuel.
... Speicherschutz ...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.
... ein Workaround für nicht API-konforme Programme ...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.
... trotz "kreativer Überinterpretation" der Dokumentation ... (sorry, aber das konnte ich mir jetzt nicht verkneifen)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
Du hast einen schnelleren Rechner als ich ;). Auf einem 1040ST (original mit 8 MHz) bekomme ich:
gcc -O0 2579 ticks gcc -O1 1424 ticks gcc -O2 1155 ticks gcc -O3 1048 ticks gcc -Os 994 ticks (schneller als O3, wie bei Dir) Pure C 940 ticks (Gewinner!)
Die -- nicht im Forum gepostete -- Variante mit lokalen statt mit globalen Variablen liefert:
gcc -O0 2365 ticks gcc -O1 779 ticks gcc -O2 806 ticks (langsamer als O1!) gcc -O3 725 ticks gcc -Os 672 ticks Pure C 672 ticks (gleichauf mit gcc -Os) Zitat... da scheint was mit der Optimierung im Argen zu sein ...
Das sehe ich auch so.
188: 30c1 movew %d1,%a0@+
18a: b1c0 cmpal %d0,%a0
18c: 65fa bcss 188 <movinv+0x2e>
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:
Gibt aber wohl auch Gegenbeispiele. Zum einen führt die nicht mehr besonders intensiv duchgeführte Pflege von m68k dazu, daß einige Code-Sequenzen die aus dem Optimierer heraus kommen, nicht mehr erkannt werden und verschiedene, m68k-spezifische Optimierungen, dadurch manchmal nicht durchgeführt werden.Hast Du dafür konkrete Beispiele?
Zum anderen sind neuere Compiler-Versionen sehr viel empfindlicher geworden was pointer-aliasing angeht, und alte Sourcen, bei denen das ignoriert wurde weil es sowieso keine Rolle spielte, erzeugen dadurch manchmal mittlerweile tatsächlich ungültigen code wenn man die Warnungen ignoriert.
Hast Du dafür konkrete Beispiele?
So funktioniert "modernes C" eben.