JMP from Subroutine (no RTS)

Es gibt 62 Antworten in diesem Thema, welches 8.090 mal aufgerufen wurde. Der letzte Beitrag (20. Juni 2022 um 16:34) ist von Sorbas2020.

  • warum sollte man mit einem JMP zurück ins Hauptprogramm springen?

    Weil $Leute von Basic und GOTO versaut wurden?

    :thumbsup:

    Und hat bei mir keinen Schaden angerichtet. :D

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • warum sollte man mit einem JMP zurück ins Hauptprogramm springen?

    Weil $Leute von Basic und GOTO versaut wurden?

    :thumbsup:

    Und hat bei mir keinen Schaden angerichtet. :D

    Man merkt das selber nicht immer so. Alleine schon, dass man das GOTO hochhält und verteidigt, ist eigentlich schon Schaden genug. ;(

  • warum sollte man mit einem JMP zurück ins Hauptprogramm springen?

    Weil $Leute von Basic und GOTO versaut wurden?

    :thumbsup:

    Und hat bei mir keinen Schaden angerichtet. :D

    Man merkt das selber nicht immer so. Alleine schon, dass man das GOTO hochhält und verteidigt, ist eigentlich schon Schaden genug. ;(

    Mit einem GOSUB ins Unterprogramm springen und mit GOTO wieder verlassen ist mir nachweislich nur 1x im Leben passiert.

    Das hatte ein F64 User festgestellt als die mein Spiel vom CPC auf C16 oder so umgesetzt hatten. :D

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Ich hab das in einigen Game Sourcen schon öfters gesehen.

    Könnte es sein, daß am Anfang des Hauptprogramms bzw. der Hauptschleife ein

    Code
       LDX #$ff
       TXS

    steht? (So gesehen z. B. bei "Elite") Auch damit wird verhindert, daß der Stapelzeiger einen Überlauf bekommt.

  • Ich hab das in einigen Game Sourcen schon öfters gesehen.

    Könnte es sein, daß am Anfang des Hauptprogramms bzw. der Hauptschleife ein

    Code
       LDX #$ff
       TXS

    steht? (So gesehen z. B. bei "Elite") Auch damit wird verhindert, daß der Stapelzeiger einen Überlauf bekommt.

    Das ist auf jeden Fall absoluter Standard-Kram. Sieht man so gut wie in jedem Programm, ob Spiel oder Demo. Meist mit SEI davor, was dann aber schon wieder an Cargo-Kult grenzt. (Anderes Thema.) =)

  • Ich hatte mal sowas ähnliches gemacht. Stackpointer gerettet, lang laufendes Unterprogramm mit JSR aufgerufen, im IRQ bei Run/Stop irgendwas mit dem Pointer rumgefummelt und mit RTS rausgegangen. Oder so.

    Dein Programm war also eine seltene Anwendung der Befehle TSX/TXS? :wink:

    Ja. Damit hatte ich mir im Hauptprogramm die Abfrage der Runstop-Taste oder eines Flags dazu erspart.

  • Ich frage mich schon seit einiger Zeit,

    ob es nicht zu Problemen mit dem Stack, in Verbindung mit Interrupthandling kommen kann, wenn aus einer Subroutine nicht RTS sondern JMP z.B zurück in eine Mainloop gemacht wird?

    Was sagen die Profis dazu?

    Wenn du in einem IRQ Handler bist, dann müsstest du mit RTI zurückspringen, weil dann ja auch noch das Statusbyte auf dem Stack ist. Generell kann man durchaus auch mit JMP aus einer Unterroutine wegspringen, das hängt davon ab wo man hinspringt. Wenn man in eine weitere Unterfunktion springt, dann ist das OK, weil diese dann ja den RTS durchführen wird. Mache ich häufiger, weil ich mir dann auch teilweise Code erspare.

    Wenn man in den Mainloop springen will muss man halt den Stack selbst bereinigen. Ob das was bringt ist fraglich, weil man mehr Befehle braucht und langsamer ist.

  • Man merkt das selber nicht immer so. Alleine schon, dass man das GOTO hochhält und verteidigt, ist eigentlich schon Schaden genug. ;(

    Böse Zungen mögen behaupten, dass auch in Hochsprachen so etwas wie throw ... catch einem goto gleichkommt... GOTO zur strukturierung eines Programms ist sicherlich schlecht. JMP (ich kann nur x86) in assembler ist wohl kaum vermeidbar, und de facto ja auch ein GOTO... Aber ein GOTO z.B. zur Fehlerbehandlung / exception handling kann ich durchaus mal verschmerzen.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • Aber ein GOTO z.B. zur Fehlerbehandlung / exception handling kann ich durchaus mal verschmerzen.

    In C-artigen Sprachen nutze ich goto gerne, um aus mehrfach verschachtelten Schleifen auszubrechen.

    Macht viel saubereren und überscihtlicheren Code, als auf jeder Ebene irgendein Abbruch-Flag zu überprüfen und sich so rauszuhangeln. =)

  • Aber ein GOTO z.B. zur Fehlerbehandlung / exception handling kann ich durchaus mal verschmerzen.

    In C-artigen Sprachen nutze ich goto gerne, um aus mehrfach verschachtelten Schleifen auszubrechen.

    Macht viel saubereren und überscihtlicheren Code, als auf jeder Ebene irgendein Abbruch-Flag zu überprüfen und sich so rauszuhangeln. =)

    Ja exakt, das ist ja quasi einem throw/catch gleich. Letzteres ist halt syntaktischer Zucker.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • Ja exakt, das ist ja quasi einem throw/catch gleich. Letzteres ist halt syntaktischer Zucker.

    Nicht direkt gleich, weil es normaler Programmfluss ist und keinerlei Ausnahme.

    Throw/catch wäre sowas wie setjmp/longjmp, aber das sollte man auch nur benutzen, wenn man es wirklich braucht. :)

  • Aber ein GOTO z.B. zur Fehlerbehandlung / exception handling kann ich durchaus mal verschmerzen.

    In C-artigen Sprachen nutze ich goto gerne, um aus mehrfach verschachtelten Schleifen auszubrechen.

    Macht viel saubereren und überscihtlicheren Code, als auf jeder Ebene irgendein Abbruch-Flag zu überprüfen und sich so rauszuhangeln. =)

    Ja exakt, das ist ja quasi einem throw/catch gleich. Letzteres ist halt syntaktischer Zucker.

    Das ist ja jetzt völliger Quatsch. Nur weil man versucht in BASIC mit GOTO ein nicht vorhandenes Exception-Handling zu simulieren, heisst das nicht im Umkehrschluss, dass Exception-Handling irgendwas mit GOTO zu tun hat.

    Wer das behauptet, hat vermutlich noch nie mit richtigem Exception-Handling gearbeitet.

    Und wer GOTO in strukturierten Sprachen verwendet, sollte vielleicht doch lieber bei BASIC bleiben. ;)

  • Böse Zungen mögen behaupten, dass auch in Hochsprachen so etwas wie throw ... catch einem goto gleichkommt.

    Das sind Leute, die von Dijkstras Aufsatz nur den Titel, aber nicht das Argument gelesen haben. ;)

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Exceptions sind noch schlimmer als GOTOs. Bei einem GOTO sieht man das wenigstens. Bei einem Stück Code kann man von außen nicht sehen, ob der Exception-safe ist.

    Noch dazu wo jeder Hinz und Kunz viel zu exzessiv mit Exceptions um sich wirft. Die sind für Ausnahme-Situationen, nicht für Regelfälle oder gar Prozessablauf-Steuerung (schauder)

    Endet dann mit lustigen catch für jede einzelne Exception, wenn man unterschiedlich reagieren möchte.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Exceptions sind noch schlimmer als GOTOs. Bei einem GOTO sieht man das wenigstens. Bei einem Stück Code kann man von außen nicht sehen, ob der Exception-safe ist.

    Klar sieht man das Code bzw. den Methodensignaturen direkt an, wenigstens sofern die Sprache Checked Exceptions benutzt (wie Java).

    Und wenn die Alternative ist "Code behandelt Fehler, indem er die einfach ignoriert und ggf. in einen intern inkonsistenten Zustand übergeht", dann doch lieber Exceptions. ;) Aber sicher, ist einfach ein nerviges Thema.

    Ja exakt, das ist ja quasi einem throw/catch gleich. Letzteres ist halt syntaktischer Zucker.

    Was die technische Implementierung angeht sind Exceptions nicht nur syntaktischer Zucker, schließlich läuft der Kontrollfluss bei einer Exception ggf. nicht nur aus einem Block raus, sondern auch aus Methodenaufrufen, und weitere Metadaten inkl. Stacktrace sind in Exceptions normalerweise auch enthalten.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ja exakt, das ist ja quasi einem throw/catch gleich. Letzteres ist halt syntaktischer Zucker.

    Was die technische Implementierung angeht sind Exceptions nicht nur syntaktischer Zucker, schließlich läuft der Kontrollfluss bei einer Exception ggf. nicht nur aus einem Block raus, sondern auch aus Methodenaufrufen, und weitere Metadaten inkl. Stacktrace sind in Exceptions normalerweise auch enthalten.

    Stimmt, und sie sind in der Regel ja auch typisiert, was ja auch von Vorteil sein kann.

    Allerdings stimme ich mit den Kritikern überein, dass sie das Verständnis über das Programm behindern können, da sie eine Art impliziten Kontrollfluss ausmachen. Aus einer funktionalen Sicht kann man sie auch als Seiteneffekt betrachten, was meistens auch unerwünscht ist. Von daher setze ich sie auch eher spärlich ein.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • Ist der folgende Code Exception-safe? Das sehe ich nur an Funktionen, die mit Throw-Specifications markiert sind. Und das sowie Checked Exceptions sind schon lange als grundlegender Design-Fehler erkannt worden. Zumindest so, wie java sie umgesetzt hat. Daraus folgte ja das berühmte "ich-mach-mal-oben-ein-leeres-Catch". Da hat man nichts gewonnen, im Gegenteil.

    Können in den folgenden zwei Zeilen Exceptions auftreten?

    int A = Funktion( 20 );

    int B = A + 3;


    Sehe ich nicht auf den ersten und auch nicht zweiten Blick.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Und das sowie Checked Exceptions sind schon lange als grundlegender Design-Fehler erkannt worden.

    Hahaha, sagt wer? Die Golang-Leute mit ihrem Großbrand von "Fehlerbehandlung"?

    Können in den folgenden zwei Zeilen Exceptions auftreten?

    Sagt Dir dann der Compiler bzw. die IDE. Das ist doch gerade der Punkt bei Checked Exceptions.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • ...oder gar Prozessablauf-Steuerung (schauder)...

    Lol, in der Ausbildung haben wir was mit Access 1.1 entwickelt, das mit einigen Einschränkungen versehen war.

    Da haben wir einiges mit "on error goto..." zaubern müssen.

    Wir haben es "Fehlerorientierte Programmierung" genannt.

    Endet dann mit lustigen catch für jede einzelne Exception, wenn man unterschiedlich reagieren möchte.

    Wie sieht denn eine schönere Alternative aus?