[comp.arch] Zero divide trapping to kernel mode

rcd@ico.ISC.COM (Dick Dunn) (05/24/88)

...Why
> > should a zero-divide need to be handled by the protected kernel,
> > rather than simply trapping to a user handler?
henry@utzoo.uucp (Henry Spencer) answers:
> Probably because practically every machine in existence routes *all*
> traps and interrupts to the kernel, which can pass them on to the user
> if it pleases.  I know of no machine, offhand, whose hardware has any
> notion of a "user handler".

Since Henry's answer, there have been responses about several machines that
*do* have the hardware to allow a user handler for exceptions.  I'll add to
the list the PDP-11, the VAX (as far as I can tell), the 286/386, the IBM
370 series, and the WE 32100.  There are probably as many machines that
would allow it as not--at least as far as the hardware is concerned.

What does it take in hardware?  The PDP-11 is a good example:

    On an exception, such as zero divide, it loads a new PC and PS, the
    latter containing the new privilege level.  You need this so that you
    can stay in user state--for example, it doesn't work with the 68000
    because that doesn't load a new PS; it just forces supervisor.  The
    68010 is a near miss here--it actually has a "vector base register"
    which could point someplace different for user and supervisor code if
    you wanted to do the switching.  But it always goes to supervisor on
    an exception.

    There must be a return instruction of some sort which is compatible
    with what was stacked by the exception, and which can be executed in
    user mode.  This is true of the 11 with the RTI instruction.

    The return instruction must verify that the return is not to a level of
    greater privilege than the returning code.  For example, on the higher-
    end (3-state) 11s you may RTI from kernel->user, kernel->supervisor,
    kernel->kernel, but supervisor->user or supervisor->supervisor, and
    only user->user.  This is necessary because the PC/PS that will be
    popped are in the address space of the exception handler.

    The exception vector must be protected.  This prevents a user program
    from altering the protection level.  (It also implies that you need a
    system call to establish the handler.)

There are other ways to make the hardware work--the 370 wouldn't work quite
this way, for example.

What does it take in software?

    You have to give a program a way to establish its own handlers for
    certain exceptions.  These will need to be reloaded on a context switch
    and some may need to be reloaded on kernel entry--depending on whether
    the kernel itself uses exceptions to do magic.  However, there may
    already be special code surrounding such uses--cf. "nofault" in older
    UNIX kernels.

    You may need user-level code to patch up the difference between the way
    the hardware "calls" a routine on an exception and the way a procedure
    in a particular language expects to be called.

I don't know of systems which have the software to do direct user-mode
exception handlers--which is perhaps curious because it doesn't seem that
hard.
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...If you get confused just listen to the music play...