Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news
From: jvh@galactus.hut.fi (Johannes Helander)
Newsgroups: comp.sys.nsc.32k
Subject: Re: A summary of the setjmp problem
Summary: setjmp on 4.3BSD + NS532 bugs.
Message-ID: <9102120318.AA21297@galactus.hut.fi>
Date: 12 Feb 91 03:18:45 GMT
Sender: news@daver.bungi.com
Reply-To: jvh@sauna.hut.fi
Organization: Helsinki University of Technology, CS Lab.
Lines: 60
Approved: news@daver.bungi.com

Now when this setjmp/longjmp stuff has been discussed so much, I'll
add my ten cents worth by noting that in any 4.3BSD or compatible
operating system all registers have to be saved in setjmp().

In 4.3 the setjmp/longjmp stuff is closely tied to signals. A
longjmp() is equal to a sigreturn(). In fact longjmp() calls
sigreturn() giving as an argument a jmpbuf that is interpreted as a
sigcontext by the kernel. Thus the definitions of sigcontext and
jmpbuf have to be equal. (Ultrix uses a couple of extra fields in the
end of the jmpbuf on the pmax, but even here sigcontext is a proper
subset of jmpbuf).

As signals are asyncronous events, all the registers need to be saved.
Sigreturn then restores all the registers. Longjmp simply patches the
return value into the jmpbuf/sigcontext r0 slot.

The same goes for Mach. The 4.3BSD emulation has to save all registers
and this is the way I wrote the code for the pc532 Mach. How the FPU
regs should be handled is on the other hand quite unclear to me. Is
a signal handler allowed to use the FPU? If so, should the FPU status
be restored after sigreturn? Is a longjmp supposed to keep the FPU
state? I guess it should be the responsibility of the program itself
(or the programmer).

Then a couple of notes on the NS532 CPU:

MOVUSi and MOVSUi use both ptb registers even if the processor is
working in single address mode. Is the TLB associated to ptb1 updated
as if the processor was executing in dual mode? (The data sheets don't
mention this :-). We solved this problem by always loading ptb1 when
ptb0 is loaded and always write to ivar1 whenever ivar0 is written to.

Whenever SBITI causes an ABT trap (page fault), the msr register will
indicate a read (data transfer) cycle -- not a read-modify-write cycle
as it should.  Thus only a read fault is recognized although it really
was a write fault. Is there any clean way to recognize this situation
(except looking at the instruction)? The SBIT (non-interlocked set
bit) works correctly. As it now stands, an SBITI instruction will
cause our trap handler to loop (always mapping the page for reading,
never for writing). Of course the SBITI instruction doesn't need to be
used on a single processor computer like the pc532, but somebody might
use it anyway...

A very dissapointing feature of the NS32532 processor is that there is
no 32-bit absolute addressing, only 30 bits -- or actually 29 since
the first bit is a sign bit -- can easily be addressed. This leads to
a maximum of 512MB of usable memory without severe complications in
the compiler and many other places. Maybe we should start using near
and far pointers :-). It was unfortunate that NS didn't choose to use
the one "reserved" addressing mode for this purpose (what is it used
for?). BTW, am I correct in assuming that 30 bit negative addresses
will point to top of memory?

Does anybody have bug lists for the processor? Are there other known
bugs? (I'm sure all processors have several and it is not nice finding
them the hard way (always many hours time wasted)).

	Johannes

jvh@cs.hut.fi -- mcsun!hutcs!jvh