Software > Coding
gcc, GEMDOS Super und Stackzerstörung
ari.tao:
--- Zitat --- Daß deine Methode bei dir funktioniert, glaub' ich gleich.
--- Ende Zitat ---
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).
--- Zitat --- Daß sie immer funktionieren muß, sehe ich ganz und gar nicht als garantiert.
--- Ende Zitat ---
Da musse ma gaanz, gaanz schaaf hingucken, dann wird die nackerte Maya schamrot und verschwindet >:D !
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) ;D .
--- Zitat --- Im Profibuch (und anderswo) steht lediglich, welche Register beim XBIOS-Aufruf gerettet und danach wiederhergestellt werden.
--- Ende Zitat ---
Nee. Da steht bloß, daß sie _gerettet_ werden. Vermutlich geht es um ihre Seelen >:D .
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.
--- Zitat --- ... weil man den - offensichtlich von TDI-Modula eingeschobenen - Funktionsprolog LINK a6,xxx nicht sieht ...
--- Ende Zitat ---
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.
--- Zitat --- ü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.
--- Ende Zitat ---
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).
--- Zitat --- ... zugesicherten Eigenschaften ...
--- Ende Zitat ---
Was soll diese jur. Formulierung? Bin ich etwa ein Händler? Ich habe nix ´zugesichert´!
--- Zitat --- Daß der Stack beim Supexec()-Aufruf so aussieht, wie er eben aussieht, wenn das XBIOS den Supervisor-Mode aktiviert hat und deine Routine ...
--- Ende Zitat ---
Ganz ohne Garantie: Es ist so und es bleibt so ;) .
--- Zitat --- ... als Callback aufruft, ...
--- Ende Zitat ---
Dieser Ausdruck bezeichnet afaik eine völlig andere Mimik. Auf Deutsch: Das ist kein CallBack (wie zB. wenn Du Dich in SystemVektoren einklinkst).
--- Zitat --- ... daß das überhaupt derselbe Stack ist ...
--- Ende Zitat ---
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!)
--- Zitat --- ... Fazit: ...
--- Ende Zitat ---
Mein Fazit: Tief durchatmen. Ich sehe mich schon wieder gezwungen, alles bis zur letzten Schraube auszubuchstabieren, was doch offensichtlich vor Augen liegt.
-------
--- Zitat ---
Zitat von: ari.tao am ...
--- Zitat --- Darauf darf jeder vertrauen. -> ProfiBuch (10) S. 36 & 202.
--- Ende Zitat ---
Dort steht, welche Register vor der Rückkehr aus dem Trap wiederhergestellt werden.
--- Ende Zitat ---
Nee, steht dort nicht, siehe oben.
--- Zitat --- ... welche Register im Trap erhalten bleiben ...
--- Ende Zitat ---
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!)
--- Zitat --- Keine der von Dir zitierten Stellen sagt etwas zur Belegung der Register, die meine von Supexec aufgerufene Funktion sieht.
--- Ende Zitat ---
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 ).
--- 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,...
--- Ende Zitat ---
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?
--- Zitat --- Ich schreibe es zum wiederholten Mal: 1. Es geht um einen 68000.
--- Ende Zitat ---
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.).
--- Zitat --- Für einen ST ist Hatari zyklusgenau. Das magst Du bezweifeln, es ist aber so.
--- Ende Zitat ---
Du meinst: für einen 68000er. Das habe ich doch gar nicht bezweifelt.
--- Zitat --- 3. Der Code ist unwiderlegbar ineffizient, ich habe ihn mir angesehen.
--- Ende Zitat ---
Das nun ist ein wirklich durchschlagendes Argument ;) .
Habe ich das falsch verstanden, daß der Hatari auch den Falcon emulieren kann?
--- Zitat --- Für einen ST ist Hatari zyklusgenau.
--- Ende Zitat ---
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:
--- Zitat von: mfro am Fr 19.08.2016, 07:36:38 ---in der STC 12/90 habe ich nichts entsprechendes gefunden
--- Ende Zitat ---
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 .
--- Zitat von: mfro am Fr 19.08.2016, 07:36:38 ---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"
--- Ende Zitat ---
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.
--- Zitat von: KarlMüller am Fr 19.08.2016, 08:54:38 ---
--- Zitat von: mfro am Fr 19.08.2016, 07:36:38 ---in der STC 12/90 habe ich nichts entsprechendes gefunden
--- Ende Zitat ---
Steht, wie er schrieb, ab Seite 79.
--- Ende Zitat ---
Sehr bedauerlich, daß das STC-Archiv da offenbar eine Lücke hat.
--- Zitat --- und bis TOS 1.04 so ist. Womit schon fraglich ist ob es mit EmuTOS geht.
--- Ende Zitat ---
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.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln