Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: How to call the bios from within process termination handlers
Message-ID: <1937@atari.UUCP>
Date: 9 Jan 90 19:03:17 GMT
References: <9001060449.AA23484@TIS.COM>
Organization: Atari Corp., Sunnyvale CA
Lines: 48

dmb@TIS.COM (David M. Baggett) writes:
>I.e., adding *just*
>	Setscreen(-1L, -1L, 1);
>to my process termination handler causes the handler to RTS to an
>illegal instruction.  Note that this call is #defined in
><osbind.h> and turns into 
>	xbios(5, -1L, -1L, 1)
>(i.e., it calls the xbios hook in dstart.o, provided with Sozobon).
>
>Saving the stack pointer before the trap and restoring it afterwards
>fixes things.

I don't believe it's a question of the stack pointer.  When you return
from the BIOS your sp is ALWAYS what it was before you went in.
(How else could anything work?)

I think it's a reentrancy problem.  The OS hooks seem to use external
storage, meaning they're non-reentrant.  Worse, they all use the SAME
external location, so in a given program, you can't call BIOS from
BIOS, but you also can't call XBIOS from BIOS! 

(Study the flow of a BIOS call which calls XBIOS when both go through
the same hook: the mainline calls BIOS, saving the return PC someplace.
That BIOS code calls XBIOS, saving it's return PC IN THE SAME PLACE!)

On the other hand, it shouldn't matter, since the Pterm call in question
never returns.

Hooks like this can be made reentrant by changing how they work:
instead of this:

	move.l	(sp)+,trapret		; save return PC
	trap	#$x
	move.l	trapret,-(sp)		; restore return PC
	rts

you could use this:

	movem.l	4(sp),d0-d2/a0-a2	; get 6 longs' worth of args
	movem.l	d0-d2/a0-a2,-(sp)	; push them
	trap	#$x
	add.w	#24,sp
	rts

This uses no external storage (and therefore is reentrant).  The point
is to give the trap the intended args without the hook's own return PC
in the way.  The first method pops the PC off and saves it, while the
second method does it by copying the args into a new stack frame.