Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.micro.68k
Subject: Re: Re: PDP11s vs the micros
Message-ID: <2784@sun.uucp>
Date: Wed, 11-Sep-85 01:30:31 EDT
Article-I.D.: sun.2784
Posted: Wed Sep 11 01:30:31 1985
Date-Received: Thu, 12-Sep-85 23:25:19 EDT
References: <1617@hao.UUCP> <847@mako.UUCP> <2422@sun.uucp>
Organization: Sun Microsystems, Inc.
Lines: 31

> In a multiprocessor system designed for transparent operation and
> which has the ability to allocate processors to tasks dynamicly, it
> is possible that a task be re-started on a different processor than
> the one that faulted.  If there is any difference in the micro-state
> between cpu revision levels, it could happen that the restart would
> fail due to incompatible micro-state.

Another problem with making information like the format of internal state
dumped on page faults and the like "private" to the particular chip is that
you make it difficult for user-mode code in a protected system to catch
faults of that sort and handle them itself.  I'm sure you all know one
infamous UNIX utility which this fouls up (I ran afoul of this one
recently).  Other programs which might want to do this include programs
maintaining multiple subtasks within a process - they could catch SIGSEGV
(or your OS'es equivalent) and do grow a process' stack if it goes beyond
the stack's boundary.

Unless the architectural spec for the machine states that there is *nothing*
a user-mode program can do to the internal state that will do anything more
than wedge the process doing it, you can't keep the state information in
user-writable space; this means you can't keep it on the user stack.
Unfortunately, that's where a user-mode RTE or whatever instruction will
usually restore it from.  You thus have to keep it somewhere like the kernel
stack or (in UNIX) the user page.  This means you have to limit the number
of such exceptions that remain outstanding or dynamically allocate space to
hold them.  Saving one such lump of state information, so that user-mode
code handling the exception is not allowed to incur another such exception
if that exception is also to be handled in user mode, should handle most of
the cases you're likely to see, but it's still a kludge.

	Guy Harris