Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!gatech!rebel!didsgn!allan
From: allan@didsgn.UUCP (didsgn)
Newsgroups: comp.arch
Subject: Re: Is the Intel memory model safe from NO-ONE ?!?
Summary: Why the trap to supervisor mode.
Message-ID: <254@didsgn.UUCP>
Date: 12 May 88 11:49:32 GMT
References: <353@cf-cm.UUCP> <3095@edm.UUCP> <20618@think.UUCP>
Organization: Digital Design Inc., Norcross GA
Lines: 75

In article <20618@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> In article <3095@edm.UUCP> rroot@edm.UUCP (uucp) writes:
> >From article <353@cf-cm.UUCP>, by mch@computing-maths.cardiff.ac.uk (Major Kano):
> >> (As an aside, I've heard of 68000 routines doing all kinds of contortions to
> >> check for/avoid overflow because the 68K traps on (eg., zerodivide) and traps
> >> into SUPERVISOR mode (believe it or not).
> >Yes, the Divide instruction seems to unconditionially except on a zero
> >divide, but if you REALLY want to ignore zero divide, you can have the
> >interrupt vector point to an RTE instruction (or an OR/RTE pair if you
> >want to set the condition code).
> 
> Read the original message again, more carefully.  He wasn't
> complaining so much about the fact that divide by zero results in a
> trap, but that it traps into SUPERVISOR mode, even though the program
> that executed the divide instruction was running in USER mode.  Why
> should a zero-divide need to be handled by the protected kernel,
> rather than simply trapping to a user handler?
> 
> Barry Margolin
> Thinking Machines Corp.
> 
> barmar@think.com
> uunet!think!barmar

The reason that you cannot trap into a user handler is that ALL programs,
both user and supervisor, use the same trap handling routine (located at the
address pointed to at location 0x14). Since the same handler is used by all
processes (including the kernal), the processor must go to supervisor mode
in order to handle what ever it wishes to do. Also, since the location of
the handler routine is stored in low memory, most MMUs will prevent a
user mode process from accessing it. So, in this architecture, the
processor must go into supervisor mode to be able to read the location
of the handler as well as handle it. If it was the kernal that caused
the trap, then appropriate recovery must be done; if it was
a user process, then the process must be marked as experiencing a
"divide by zero" trap.

A possible change to this architecture would be to let each process have
its own "trap vectors" stored in the process's low memory and have the
processor fetch the vector as normal, in user mode, and execute the appropriate
routine as necessary. The problem with this is each type of trap must be
set as either a user mode trap or a supervisor trap. The 68000 supports an
instruction called "TRAP #x" where x ranges from 0 to 15. Under most systems,
one of these TRAP instructions is used to communicate with the operating
system. Thus, some of these TRAP instructions must go into supervisor mode
and to a common routine (as it is above) and perform the necessary function.
All of this implies a new (priviledge) set of instructions for loading and
modifying the "trap type mask" (user or supervisor trap) for each process.
Currently, the 68000 supports 48 different types of traps (note:
approximately 14 are reserved, but must be considered for the future)
while the 68020 uses 64 (same note applies). Thus, during a context switch,
all this new information must be saved and restored each time. In order to
avoid this, (I'll assume, and yes I know what that stands for :-) ) the
designers said, "Since the processor, in supervisor mode, can simulate to
each of the user mode processes exactly what happended in the trap, and can
place that process in the correct position to perform the (local) trap handler,
all traps shall be to supervisor mode. This simplifies the hardware and
does not overly complicate the operating system. The OS can easily control
what type of response or action is required for each trap, including allowing
a "user trap" instruction. (This is where a user program, issuing a 'TRAP #x'
call can have a local handler to perform whatever function is desired. An
example of this capability was seen in Motorola's VERSAdos Operating System.)

So, in conclusion, a trap to supervisor mode on a zero divide is not
unreasonable. Rather than complicate the hardware or second guess whether
the user wishes the trap or not, Motorola made it the responsibility of
each OS to determine what the proper response should be. If "no action" is
desired, so be it. But, if a special routine must be executed to flag to
the process that something is wrong, then that is also possible. This allows
the 68000 to remain very flexible.


Allan G. Schrum

gatech!rebel!didsgn!allan