[comp.sys.encore] Mach threads syscalls

uemura@isvax.isl.melco.co.jp (Joe Uemura) (12/14/89)

I've been experimenting with Mach threads (not Cthreads)  on  our
Encore  running  Mach  0.5.  After  poking around several include
files, I was able to get a thread created and got it  running  by
following the hints presented in the "Mach Kernel Interface Manu-
al". Since most of what I did was guess work, I am looking for  a
more  detailed  explanation of how Mach threads syscalls actually
work, specially how much of the thread  state  I  should  provide
through  the set state syscall. I'm interested in both the syntax
as well as the semantics of the threads syscalls. I would  appre-
ciate  any pointers to documents, tech reports, actual code exam-
ples, anything. I believe I have read most of the CMU Mach papers
but  since  threads  calls  are machine dependent, I haven't been
able to find much specific (Encore/NS32K) information  concerning
the calls.

Please email responses to me.

David.Black@G.GP.CS.CMU.EDU (12/16/89)

Hope this makes it to Japan; that mail path is wild.

The only machine-dependent thread syscalls in Mach are thread_get_state and
thread_set_state.  These calls manipulate the hardware state defined
in <mmax/thread_status.h>.  The registers in the ns32000_thread_state
structure defined there correspond exactly to the hardware registers in the
ns32000 architecture.  The only restriction imposed by Mach is that it will
ignore any attempt to change the supervisor PSR flags (I, P, S, and U).
To understand exactly how these registers work, you need to consult the
following:
	1.  A Series 32000 Instruction Set Reference Manual (which will
		tell you more than you ever wanted to know).
	2.  The function/procedure calling convention for the language
		in which you're working (to find out how the compiler
		and runtime use these registers).
If you have source to the cthreads library, you could look at how it sets
up a new thread for an example.  One note of caution:  The MOD register
must be set up; failing to get this right can cause strange anomalies
(page faults, and sb-relative memory references don't work).

--Dave