Clean exit of code

[Vikke]

Hi,

Clean exit of code, to return t the CLI or Workbench was never important for me when I did my ASM coding some 20-25 years ago.

Can someone help me with code for initializing and exiting to gracefully return to the CLI or WB? I need code that compiles on Asm-One v1.20.

I can make this myself, but I'd rather not spend time on this, but rather on coding other stuff. I'm going to setup a website for oldskool-coding on Amigas during the weekend, with sources and resources. But these example programs should be able to exit gracefully.

Hopefully I can get some help here, otherwise I'll have to make it myself.

[thomas]

http://eab.abime.net/showpost.php?p=671760&postcount=22

[Vikke]

So, I made my own, but I read online what other suggested to be done.

Especially the text of xeron on Amiga.org http://www.amiga.org/forums/showpost...19&postcount=3 was of great help.

It is made to work on OCS Amigas and can be found in all code examples at http://vikke.net

[Photon]

Close any opened libs, then moveq #0,d0;rts if you haven't turned off interrupts etc

Else you just restore what hardware registers you changed and do the same. (To restore the copper list pointer(s) you must get the current pointers from graphics.library at the start).

It's considered good form to restore all registers (except d0) before exit.

If you want to be compatible with Amigas with graphics cards, you should wait for vertical blank twice and restore the Intuition view the program was started from.

[BippyM]

Why do we clear d0?

[thomas]

D0 contains the return code. If you return 10 or higher, you get a "command xy failed return code nn" message. If you return -1 you get "xy: unknown command".

[phx]

Originally Posted by Photon

It's considered good form to restore all registers (except d0) before exit.

Why? I would expect that the caller saves and restores all registers anyway.

[Photon]

Originally Posted by phx

Why? I would expect that the caller saves and restores all registers anyway.

Well, that knowledge comes from aquirable experience/OS documentation. Having it there makes the code independent from relying on that the caller does that. I have the experience and don't do it, so I was probably a bit overzealous there. (But I certainly like code that is independent from experience and OS documentation.)

Some startups wait for end of frame, then set copperptr and trigger the new copper, even though it's not necessary. This is verbatim, logical, independent code that works - but you could argue the same there, "everyone knows it's not necessary". I think spelling it out is sometimes pedagogical and sensible.

[Toni Wilen]

Commands don't need to save/restore registers, except of course stack pointer

Some startups wait for end of frame, then set copperptr and trigger the new copper, even though it's not necessary. This is verbatim, logical, independent code that works - but you could argue the same there, "everyone knows it's not necessary". I think spelling it out is sometimes pedagogical and sensible.

Sometimes this is 100% necessary, for example if you start interlaced copper list or copper list has side-effects (writes to intreq, uses blitter etc..). Triggering copper list twice very quickly (once by manual COPJMP1 write and then again when vblank starts or vice versa) can cause random "unexplained" glitches.

[Photon]

I know the exceptions, and I bet you see some weird and sometimes incorrectly programmed startups that you have to handle But as I see it the topic is about a normal startup and what should be in it.

If I were to nitpick I could f.ex. say that you don't have to save/restore the stack pointer, because if it were trashed you wouldn't RTS to the code that restores it.

Startup code is a relative thing. There is no way to write a perfectly safe wrapper, if you were to do proprietary things with the hardware as if it were your own, if it's executed while a task using a shared hardware resource is running, for example running a custom hardware-musicplayer while running a modplayer with the OS.