gcc, GEMDOS Super und Stackzerstörung

[ari.tao]

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  !
Und: Ich garantiere für gar nix! Was ich hier im Thread absondere, könnt ihr benutzen oder nicht benutzen - aber immer auf eigenes Risiko! Vorsichtshalber stelle ich es unter GPL (soweit mein eigenes CopyRite betroffen ist)  .

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  .
Aber das führt jetzt zu einer ganz anderen Diskussion, nämlich darüber, was das an XBIOS_38 übergebene Unterprogramm - nennen wir es ´Client´ - tun darf oder muß - oder eben auch nicht.

... 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.
Ein ASM-Programmierer sollte damit überhaupt kein Problem haben. Was das M2-Bsp. zeigt, ist lediglich, daß die Parameter-Übergabe an den Client auch aus einer Hochsprache heraus geht - wenn man die CallingSequenz des Compilers kennt.

ü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.
Ich habe das Gefühl, daß bei Euch immer der Stackwechsel im Kopf herumgeistert, den GEMDOS_32 (Super) vornimmt. Den gibt´s aber bei SupExec gar nicht! Ich habe da noch ebbs in meinen NotiZen gefunden "Benutzt aber den UserStack & Reg. A0, siehe ´Atari intern´ S.320". (Aber auch diese Lit. ist mir derzeit unzugänglich. A0 ist vielleicht ein Schreibfehler, müßte imho heißen D0).

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

Zitat von: ari.tao am ...

Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.

Dort steht, welche Register vor der Rückkehr aus dem Trap wiederhergestellt werden. 

Nee, steht dort nicht, siehe oben.

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

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

Ad Benchmarking:
Dazu ist doch wohl alles schon gesagt?

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.
Nochmals vielen Dank, @czietz , für das Teil!
(Obzwar ich selten in die Verlegenheit komme, einen RAM-Test machen zu _müssen_ (in den letzten zehn Jahren gerade zwei mal). Und ja, gerade weil TT & F30 so viel mehr RAM haben (können), ist die Geschwindigkeit nicht ganz uninteressant.).

  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 .

Habe ich das falsch verstanden, daß der Hatari auch den Falcon emulieren kann?

  Für einen ST ist Hatari zyklusgenau. 

Du meinst sicherlich: Für einen 68000er... (und nicht etwa eine PAK oder so).
Das klang für mich vorher so, als beziehe sich Deine Aussage auch auf vom Hatari emulierte 68030er. Und da bleibe ich bei meinem (personalisierten) Vorbehalt - bis zum Beweis des Gegenteils.
Daß ich für den 68000er problemlos Takt-Zählen kann, hatte ich ja schon kundgetan. Kann ich ganz ohne Hatari. Dennoch herzlichen Dank für den Link zu YACHT!

[czietz]

Ich kürz das mal ab: Wenn Du aus dem Programm im User Mode das XBIOS aufrufst -- nein, sogar bei jedem TRAP -- wechselt die CPU automatisch den Stackpointer (also A7) vom User Stack Pointer (USP) zum Supervisor Stack Pointer (SSP). Damit zeigt der Stackpointer erst einmal ganz woanders hin als auf Deine Parameter. Irgendwo bevor der XBIOS-Dispatcher die Supexec übergebene Funktion aufruft, macht er ein MOVE USP, A7 um den Stack wieder auf den User Stack Pointer zurückzustellen. Nur deshalb funktioniert der Code in SUP_TEST.

Dummerweise steht in keiner (mir bekannten) Dokumentation zu Supexec, dass das XBIOS immer aktiv den Stack-Pointer mit MOVE USP, A7 zurückstellt! Das heißt: Doch, anders als Du glaubst, gibt es auch bei Supexec einen Stack-Wechsel, der nur vom XBIOS-Code wieder rückgängig gemacht wird. Es kann aber TOS-Versionen geben, die den Stack belassen wie er ist und dann findet die Funktion ihre Parameter nicht. => Keine saubere Lösung.

[mfro]

in der STC 12/90 habe ich nichts entsprechendes gefunden, in 4/88 gibt's dagegen was sehr Ähnliches (ST PASCAL):
http://www.stcarchiv.de/stc1988/04/fonts-unter-st-pascal-plus

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", die Atari arge Probleme bereitet hat (z.B. beim TT oder beim Falcon, wo Vieles, was Usus, aber nicht dokumentiert war, eben nicht mehr tat).

Ein API (das XBIOS ist ein solches) macht Zusicherungen. Und zwar nur genau die, die da stehen, keine anderen.

Aber das werden wir heute nicht mehr richten, dafür ist's schon ein paar Jahrzehnte zu spät.

[KarlMüller]

in der STC 12/90 habe ich nichts entsprechendes gefunden

Steht, wie er schrieb, ab Seite 79.

Allerdings schreibt der Autor schon das es eine undokumentiere Eigenschaft des Trap-Handler ist, an der er sich orientiert und bis TOS 1.04 so ist. Womit schon fraglich ist ob es mit EmuTOS geht.

[ari.tao]

Ich kürze das auch mal ab:
Wenn der Client im Zweifel ist, welcher Stack gilt, kann er ja selber den nötigen setzen. Wie schon gesagt, auf ASM-Ebene hätte wohl kaum einer ein Problem damit.
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...
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.

in der STC 12/90 habe ich nichts entsprechendes gefunden

Steht, wie er schrieb, ab Seite 79.

Sehr bedauerlich, daß das STC-Archiv da offenbar eine Lücke hat.

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.

[mfro]

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...
Man lese das Vorwort im ProfiBuch(10) S.2 .

Die Bemerkung verstehe ich nicht. Supexec() ist offiziell von Atari dokumentiert (Originaltext s.u.). Bloß deine Art der Anwendung eben nicht.

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.

Soweit so gut. Haben wir nie bestritten. Supexec() (die XBIOS-Funktion) nimmt seinen Parameter (die Adresse der auszuführenden Funktion) auf dem Stack entgegen.

Die originale Atari-Dokumentation (die - wie Vieles, was schriftlich von Atari kam - leider ein wenig schwach ist) sagt übrigens genau das (und nicht mehr):

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

Dein Code (der kein Bestandteil des XBIOS ist) setzt aber weiterhin voraus, daß dein vorher noch weiter oben angelegter Stackframe aus deiner Funktion heraus genauso erreichbar ist. Davon steht kein Wort in der Dokumentation. Die Tatsache, daß das funktioniert - davon bringst Du mich nicht ab - ist meiner Ansicht nach reiner Zufall beziehungsweise eine undokumentierte Eigenschaft der Supexec()-Funktion. Womit wir wieder bei "wenn's funktioniert, ist's richtig" wären.

Offensichtlich bist Du nicht der Einzige, der sich darauf verläßt. Ich habe mal im MiNT-Kernel nachgeschaut, wie der das macht. Eigentlich völlig anders, trotzdem baut er einen Stackframe mit evt. vorhandenen (5) Parametern auf, so daß dein "Trick" auch dort funktionieren würde.
Warum gerade 5? Keine Ahnung. Wahrscheinlich, weil die MiNT-Entwickler ein Programm gefunden haben, das sich genauso auf diese undokumentierte Eigenschaft verlassen hat, das sie gerne mit MiNT lauffähig gehabt hätten. Das brauchte halt 5 Parameter. Der Nächste, der mit 6 Parametern daherkommt, guckt in die Röhre.

Die "fünf Parameter-Sache" ist übrigens auch in MiNT undokumentiert (man sollte sich also lieber nicht drauf verlassen) und war mir bislang unbekannt.

[ari.tao]

Die Bemerkung verstehe ich nicht.

Dann will ich das noch mal anders (und konkreter) formulieren:
   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.

  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.
Da bin ich empfindlich.

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

So, nun zum hoffentlich endgültig letzten Wort über den Stack in XBIOS_38:
Ich habe die andere der beiden zitierten Literaturen wiedergefunden, nämlich
      Brückmann et al. "Atari ST intern" Data Becker GmbH, Düsseldorf 1985
      ISBN 3-89011-119-X
Das Buch enthält ab S.207 ´Das BIOS Listing´. Da man davon ausgehen darf, daß es sich nicht um eine Raubkopie handelt, gehört das somit zur offiziellen Doku von Atari. Auf S.220 findet man SupExec; es ist ziemlich kurz:

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

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

[czietz]

           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.

Weil dieser Stack ein paar Zeilen darüber mit MOVE.L USP, A7 explizit wiederhergestellt wird...

Ist dies nun endlich überzeugend?

Bestätigt ein BIOS-Listing aus dem Jahr 1985 (also vermutlich von TOS 1.00), dass alle anderen TOS-Versionen auch das MOVE.L USP, A7 im XBIOS-Dispatcher haben? Vielleicht haben sie es, vielleicht haben sie es nicht. Ich möchte mich nicht darauf verlassen, ohne in jeder einzelnen TOS-Version nachgesehen zu haben und bleibe daher für die entsprechende Stelle in YAART bei Super() in der mit Parametern aufgerufenen Funktion -- bedanke mich aber dennoch für die interessante Diskussion.

  ...im MiNT-Kernel nachgeschaut... 

Wo genau bitte?!

Dort wo man es vermuten würde: in xbios.c.

[mfro]

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

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.

Zu erwarten, dass ein Betriebssystem diesen ausgeklügelten Mechanismus (der dazu gedacht ist, das OS vor wildgewordenen User-Programmen zu schützen) aushebelt, aufwendig alles wieder rückgängig macht und noch dazu den Stack im Trap (abhängig vom Prozessor und seinem spezifischen Stackframe-Format) so aufbereitet, daß er aussieht, als ob nichts passiert wäre, ist (für mich zumindest) nicht unbedingt naheliegend (und - aus heutiger Sicht - für ein OS m.E. sogar mehr als hanebüchen).

Nichtsdestotrotz macht TOS genau das (ohne es irgendwo zu dokumentieren) und Du verläßt dich drauf.

Anmerkung: MiNT macht's übrigens richtig und schaufelt - wie bereits geschrieben - (wiederum undokumentiert) lediglich aus Kompatibilitätsgründen die genannten fünf Parameter auf seinen eigenen "heiligen" OS-Stack (xbios.c, Zeile 85ff.).

Welche Argumentation die richtige ist, werde ich mit wiedergefundener Doku weiter unten beweisen.

Auf deine (meiner Ansicht nach fragwürdigen) "Beweise" werde ich nicht im einzelnen eingehen. Die (nach meiner Kenntnis nach einzige) offizielle Atari-Dokumentation zu Supexec() habe ich (buchstabengetreu und komplett) gepostet. Sie stammt aus "A Hitchhiker's Guide to the BIOS" (ich meine mich darüber hinaus noch an einen gleichlautenden, schlecht kopierten "Fresszettel" im Atari-Developer's Kit zu erinnern, finde den aber gerade nicht). Alles andere ist entweder dort abgeschrieben oder eine mehr (Profibuch) oder weniger (die mit dem roten Einband) professionelle Interpretation des ROM-Inhalts (die Einschätzung der Professionalität ist meine eigene, der muss man nicht unbedingt folgen). Jedenfalls ist das *nicht* die offizielle Dokumentation (die konnte nur von Atari kommen).

Dass bei derart dünner Dokumentation die Interpretationen herhalten mussten, daran ist Atari - zumindest zum Teil - natürlich selbst schuld. Ich will auch das Profibuch ganz bestimmt nicht schlecht machen. Angesichts der außerordentlich knappen Atari-Doku war es toll, daß es "die Bibel" überhaupt gab und die Jungs waren die ersten und einzigen, die zwischen "offiziell dokumentiert" und "aus dem Verhalten interpretiert" unterschieden haben. Nichtsdestotrotz ist es eben *nicht* die offizielle Doku.

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

Eine API-Dokumentation beschreibt das Interface und so viel vom Verhalten, wie sich nicht mehr ändern wird. Alles andere ist Interpretation.

[mfro]

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

Irgendwie will mir das noch nicht ganz aus dem Kopf. Ich habe den leisen Verdacht, daß das mit pointer aliasing zu tun hat und sich der gcc dadurch in einen Optimierungsversuch versteigt, der letztendlich in schlechterem Code resultiert.

gcc -O3 hält den Pointer p in zwei Adressregistern vor, einen zum Lesen und Beschreiben der Speicherstelle und einen zum Vergleich mit start.

Pointer aliasing könnte der Grund dafür sein. p könnte ja schließlich patt2 überlaufen.
Daraufhin habe ich versucht, p als __restrict__ zu definieren, aber "unser" gcc kennt zwar das Schlüsselwort und akzeptiert es, erzeugt aber genau denselben Code (scheint also nichts Rechtes damit anzufangen zu wissen).

[1ST1]

Zur Qualität des Profibuchs: Aus meinem damaligen Umfeld habe ich mitbekommen, dass Reschke und die anderen Autoren des Profibuchs sehr viel mit Herrn H.Müller, Softwareabteilung, Entwicklerbetreuung bei ATARI Raunheim kommuniziert haben, teils auch direkt oder indirekt mit Leuten aus Sunnyvale. Das Profibuch ist sehr fehlerfrei, die Autoren haben viele schwammige, unpräzise Aussagen in den Atari-Dokus mit den Leuten abgeklopft, manches auch erst mit Testprogrammen "festgezurrt" wo es die Atari-Leute selbszt nicht so genau wussten. Diese Leute, auch z.B. der Krohmke (KAOS, Magic), Kowalewsky (bevor er den Job selbst übernahm) gingen in Raunheim ein und aus.

Die Data-Becker Bücher haben allgemein einen nicht so guten Ruf. Aber so schlecht waren sie auch wieder nicht. Das ST-Intern kenne ich nicht (habe aber inzwischen eins im Schrank stehen) aber das 64-Intern, welches als Knüller das 64er ROM-Listing kommentiert drin hatte, das hab ich damals geliebt.

Ich glaube auch nicht, dass ATARI das Verhalten einer so wichtigen Systemfunktion so inkompatibel von TOS 1.00 zu späteren Versionen im Verhalten einfach ändern könnte, das hätte ja eine dokumentierte Inkompatibilität bedeutet, die man nur mit erschwertem Workarround (TOS-Version abfragen, verschiedene Varianten des Systemaufrufs verwenden) hätte umschiffen können. Nein, daran gaube ich nicht. Sowas muss sich unter gleicher Funktionsnummer gleich verhalten, egal unter welcher TOS-Version.

[mfro]

... das hätte ja eine dokumentierte Inkompatibilität bedeutet ...

Eben nicht. Darum geht's ja hier seitenlang. Die Funktionalität ist *nicht* dokumentiert.

[1ST1]

Haltet euch einfach an das was im Profibuch steht.

[KarlMüller]

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.

[ari.tao]

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

..., 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.
Der ´Hitchhiker´s Guide´ ist übrigens auch von 1985. Und in meinem Developer´s Kit vom Dez. 1993 (vermutlich eines der letzten, die Atari ausgeliefert hat,) habe ich genau wie Du nix gefunden.

  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?

[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]

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

• 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]

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

[mfro]

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)

... da scheint was mit der Optimierung im Argen zu sein ...

Das sehe ich auch so.

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: [Auswählen]

  188:       30c1            movew %d1,%a0@+
  18a:       b1c0            cmpal %d0,%a0
  18c:       65fa            bcss 188 <movinv+0x2e>
 

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