Re: Syscall (was: Re: [MiNT] DATE/TIME cookies)

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Thu, Feb 25, 1999 at 05:54:57PM +0100, Konrad Kokoszkiewicz wrote:
> 
> Also, one of things I dislike very much there is the operation of copying
> (physically) the parameters from the user stack to the supervisor stack.
> The only problem avoiding this is that particular MiNT functions are
> written in C and it implies parameters on stack. Since it is supervisor
> mode, it is supervisor stack.
> 
> I see no reasonable way (for now) to avoid that. Of course, we could let
> MiNT use user stack as supervisor one (move.l usp,sp or something) and
> access all stacked parameters less or more directly, but this may demand
> that user processes will have to allocate more stack space for themselves
> - i.e. to satisfy both their requirements and the kernels.

I have solved that in my current development TOS by passing a pointer to the
real arguments to the functions. If you put that pointer in an address
register (and do some ugly tricks with gcc - PureC han handle this better
since pointer arguments *are* passed in A0,...), you get quite nice code.

However, this requires modifications to all functiosn called from the trap
handler, *and* you can't call these functions directly from other code.
However, the trap handler becomes quite short.

> Maybe I am missing something, but this made me think that the Motorolas
> concept of a separate user and supervisor stack is a bit silly.

No, this is quite reasonable. IMHO, the problem is hooking functions into
the trap handler that want their arguments on the stack.

> Another thing is the reentrancy. Since we're using TOS BIOS and XBIOS,
> no full reentrancy is possible, if a BIOS/XBIOS function isn't completely
> replaced by MiNT. So, the reentrancy issue may currently apply only to the

As a side effect, my current BIOX/XBIOS are reentrant - I have not yet
touched GEMDOS.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen