🚀 go-pugleaf

jamiep@ncoast.UUCP (Jamie Purdon) Writes:
:EXEC task switching will definitely use your "user" stack.
:I see that this situation has "bit" you, since you need to 
:allow for this in your "light weight process code".
: 
:You can change EXEC's behaviour, though, by patching the tc_Launch
:and tc_Switch fields in your task structure.  These are
:functions that EXEC vectors through just before and just
:after switching your task.  You might be able to, at these
:points, change the stack areas in use by EXEC.  This way
:you could avoid have to check/allow 80-100 bytes of stack
:only for EXEC use.

	Yes, that was the first thing I looked at.  Unfortunetly, by
the time tc_Launch/tc_Switch is called, the user registers have already
been pushed on the stack!  It may be possible to modify tc_Switch so
further custom-chip register saving will go elsewhere, but the basic
(~64 bytes) register state can't be avoided without actually modifying 
the EXEC library entry points, and even then it may not work because I
doubt EXEC uses its own entry points.

	But, actually, it doesn't matter too much.  This need for a large
minimum stack problem only effects the number of small LWPs one can
have running (those which do not need to make other calls from within
them).... In most practical cases LWPs will call Exec, Graphics, Intuition,
or Dos, and thus need from 512 to 2K working stacks... the additional 96
bytes of overhead are lost in the noise.  I've already got asynchronous
notification working via message ports, and intend to add a new call that
allows one to make a subroutine call using the 'master stack' ... that
is, main()s stack, to allow one to have LWPs with small stacks which are
still able to make calls to routines which need larger stacks... i.e.,
switch to a larger stack for the duration of the call then switch back.

						-Matt