Preemptive threads for SPARC

[Sean Holdsworth]

As an extension to the recent problems raised regarding implementing a
thread package for sparc based machines running SunOS, I'm now trying to
extend the ideas to cover preemptive (signal based) scheduling rather than
just cooperative scheduling.

I'm afraid its the usual story about something which was relatively easy
to implement in 680x0 code being near impossible for sparc. The scheme I
use is to make thread preemption signal driven. I arrange to catch this
signal using a separate signal stack for the signal handler. I look in the
sigcontext structure, passed to the handler as a parameter, to find things
like the PC, nPC and icc of the thread when it was interrupted. These I
push onto the top of the user stack for that thread, taking care to modify
the saved SP to reflect this.  Then, instead of returning normally from
the handler, I modify the saved PC and nPC so as to `return' to an
assembler written routine which completes saving the context of the
interrupted thread, including flushing its register windows, and then
jumps to a scheduler routine.

So far so good. The problems arise when the scheduler has selected the
next thread to run and it has to reestablish the context of the thread to
be resumed. The scheduler has the saved stack pointer of this thread and
on the thread's stack lurk the rest of its context including the PC and
nPC. Now for the problem: I can restore all registers other than SP and
the PC easily but I can't figure out how to complete the job.

I think I've got a partial solution to the part of the problem that the
nPC address may not directly follow the PC address by using a delayed
control transfer couple; doing the equivalent of

	jump PC
	jump nPC

causes the instruction at address PC to be executed and execution to
continue as normal from address nPC. The 'slight' problem here is that
when it comes to executing this sequence all the other registers must have
been restored but the jump instruction requires the address to be in a
register...

Its interesting to see how SunOS has got round this same problem. The code
which restores the context after an interrupt handler has run, and which
is entered when the handler function returns, seems to restore all
registers other than g1, o0 and the sp and then makes a call to system
call number 139.  The effect of making this call seems to be to complete
the restoration of context and to put the user back to where it was at the
point of the signal.  If you look in /usr/include/syscall.h this is marked
as `unused' but seems to be put to good use in this context ;-)

Any hints, tips or suggestions of why I'm doing it all wrong and should be
doing it using method X very much appreciated. Please reply by email and
if I get a sensible story out of this I will summarize.

                             Sean Holdsworth.
   Janet: seanh at uk.ac.man.cs                        Tel: +44-61-275-6294
   UUCP:  ...!uunet!mcsun!ukc!man.cs!seanh          Fax: +44-61-275-6280
   Inet:  seanh%cs.man.ac.uk at nsfnet-relay.ac.uk     Int: 6294