Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!cornell!uw-beaver!june.cs.washington.edu!robertb
From: robertb@june.cs.washington.edu (Robert Bedichek)
Newsgroups: comp.sys.m88k
Subject: Re: Exception handling in the 88's
Message-ID: <1991Apr8.191736.9799@beaver.cs.washington.edu>
Date: 8 Apr 91 19:17:36 GMT
References: <28961@dime.cs.umass.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)
Distribution: na
Organization: Computer Science & Engineering, U. of Washington, Seattle
Lines: 60

In article <28961@dime.cs.umass.edu> black@par1.cs.umass.edu.CS.UMASS.EDU (David K. Black) writes:
>
>In the MC88100 User's manual on pages 6-8 and 6-9 (Section 6.4.2)
>there apears a discussion of two methods for exception processing
>in the 88's.  To summarize:
>
>Method 1: Disable interrupts etc and don't save any context to memory.
>Use the rte instruction to restore control registers.  Shadowing remains
>disabled and a non-trap exception will crash the machine.

The "disable interrupts" step is done by the hardware on every exception.

>Method 2: The exception handler saves control register context to memory
>and shadowing is re-enabled, allowing for nested exceptions.  
>
>My question is: Under what cicumstances is the first method acceptable?
>Are there any OS code writers within "the sound of my voice" who have 
>actually confronted this problem?

When you want to do something simple and short and you can stay in
assembly code.  For example, you might have a system call handler
that does something simple and you want to make it fast because it
is called often.  Another example: handling some of the FP exceptions
that occur when there isn't really an error (like converting 2**30 from
FP to integer) and that might occur quite often.

With method 1 you want to stay in assembly code because when an
exception is taken the floating point unit is frozen.  It takes a bit
of work to unfreeze it.  The FPU is used by integer multiply and divide.
C compilers sometimes generate * and / to do pointer and array arithmetic,
so you have to avoid C.  I suppose you could write the code and have
egrep check the .s file to make sure there were no multiply or divide
instructions, but what I've seen is just to stay in assembly.

>In general, would anyone  care to comment on exception processing in 
>the 88's in general?  Any caveats to be known? etc.

To handle FP exceptions, get Motorola's handlers.  It is way too tricky
to write from scratch.  I you would like a starting point for non FP
handlers and you don't have access to any 88k kernels, ftp pub/g88.tar.Z
from cs.washington.edu and look at hmon/monlow.s.

With method 2, you

a. check to see if there was a DMU fault
b. reenable the FP unit by doing an rte
c. save the users registers

when you do b., you might get FP faults and your code needs to handle
this.

>If all this is of little interest (imagine that!) personal replies will
>be greatly appreciated.
>
>David Black

I posted this because others might be interested and to let others
correct me and/or to save them the effort of responding.

	Rob