To: perot@pallas.amp.uni-hannover.de
Subject: Re: STIK: Important inquiry, please read !                                      


On Fri, 27 Dec 1996 11:29:10 Peter Rottengatter <perot wrote: 
>
>This concerns only programmers. If you're not working on any client, 
>server, module, etc. for STiK ;-) then you do not need to read this.
>
----- snip ----- re: g_xxx and CONFIG problems
>
>The g_* calls have been discussed earlier. Right now they contain an AES 
>call to give some CPU time to the system, just in case neither MiNT nor 
>MagiC is installed. This is an intolerable situation, as the AES call is 
>done in an improper way. My first attempt to fix this by adding another 
>parameter being the address of the AES binding's global array has been 
>criticized heavily, mostly by Martin. He is certainly right in some points, 
>and we'd probably be happier if these calls are scrapped completely, which 
>is what Dan suggested. I'd guess both functions have been used very little, 
>if at all apart from Dan's CAB.OVL. At a later time we can discuss a 
>proper way to implement a means to make CPU time available on nonpreempting
>systems.

This problem will have to be addressed at some time, and when that time comes
there is one thing that might be useful to remember.  I refer to that 'extra'
XGEMDOS function $C9, which we discussed a while ago (\AUTO\ boot test).
AFAIK this is actually the _only_ AES call which does not concern itself with
the identity of the caller, and therefore does not use any AES arrays.
(In fact it takes no parameters at all.)

I think I mentioned before that I found some references to this code in an
early discussion on MultiTOS, where it was said to do exactly what we need
to be done.  Namely to yield to the taskswitcher, so other tasks (or ACCs),
can be activated.  It was therefore also called 'appl_yield', although it
does not really 'belong' in the appl_ 'family', since that uses XGEMDOS $C8
which always requires AES arrays.

Since this 'appl_yield' does not use any AES arrays, it should be legal in
both GEM and TOS programs, which is another great advantage.  Naturally it
can not be used from interrupts, but it could be called from an event-
driven scheduler such as we have discussed earlier, or from any STiK routine
that is called by the 'main' code level (non-interrupt) of any client.

I realize that there is another 'appl_yield' defined, which exists only for
PC-GEM and MagiC, but not for any version of Atari's TOS.  But the $C9 code
exists under MagiC too, and should be faster since it needs no parameters.

I suggest we try to find out more about this function, which must surely be
documented somewhere.  If we can find that documentation, and if it agrees
with the impression I have of how it is implemented and can be used, then
it may become a very useful part of some future STiK functions.

PS:  I sent this as private mail to avoid the confusion otherwise possible.
     I'm quite certain that would have resulted in another 'legality' debate,
     which we don't really need right now.  Either we can find doc's for it
     and may use it, or we don't find any and have to make do without it.
     This is obvious, so no debate is necessary.
DS.
-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
