black@par1.cs.umass.edu (David K. Black) (04/08/91)
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. 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? In general, would anyone care to comment on exception processing in the 88's in general? Any caveats to be known? etc. If all this is of little interest (imagine that!) personal replies will be greatly appreciated. David Black
robertb@june.cs.washington.edu (Robert Bedichek) (04/09/91)
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
jfriedl@NATASHA.MACH.CS.CMU.EDU (Jeffrey Friedl) (04/09/91)
In article <28961@dime.cs.umass.edu>, black@par1.cs.umass.edu (David K. Black) writes: |> 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. |> |> 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? Well, any time that you don't need to do anything because of the interrupt, or if what you need to do is reeeeeeally small. |> Are there any OS code writers within "the sound of my voice" who have |> actually confronted this problem? I wrote the exception handler for the Omron Luna/88k (4-processor machine, runs mach). I had none of the 'method 1' cases. |> In general, would anyone care to comment on exception processing in |> the 88's in general? Any caveats to be known? etc. Keep abreast of the 'General Information' and 'Errata' sheets for the processor. My understanding of the 'General Information' items is that they are bugs that won't be fixed. For example (and from the top of my head -- it's been awhile -- best if you check with Motorola), the first of the two instructions per vector slot must be a NOP. This is pretty important to know! There are various others.... I'd love to get my hands on other 88k machines, to test some wild cases. For example, consider the following executed in user space: load r2/r3 with a HUGE number, load r4/r5 with NaN. fmul.ddd r31, r2, r2 fadd.ddd r6, r4, r4 If you've written an exception handler, you should know why this is an interesting situation. If you haven't written a handler, but will soon, you should think about stuff like this! (-: *jeff* ------------------------------------------------------------------------------ Jeffrey Eric Francis Friedl jfriedl@cs.cmu.edu -or- jfriedl@omron.co.jp Omron Corporation, Section RZE, Shimokaiinji, Nagaokakyo-city Kyoto 617, Japan Currently, visiting researcher to the MACH project, Carnegie Mellon University
aduane@urbana.mcd.mot.com (Andrew Duane) (04/09/91)
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. >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? I have seen some of the responses to this so far, and thought that it would be appropriate for me to cast the single "yes" vote. I am doing interrupt and other locore work for the motorola MVME188QP quad processor board. We have designed a set of "fast" interrupts that are propagated from processor to processor to do hardware operations such as updating the IEN enable masks. This requires no context to be saved, and was designed around being very fast for the interrupted processor, so we do it in about 20 instructions or so right at interrupt time, before any saving or re-shadowing is done. At RTE from this, any other pending exceptions will he handled normally. BTW, your characterization of "crash"ing the machine on another exception is not accurate. The chip takes an error exception, the only one that is allowed with shadowing disabled. For many platforms (the 188QP) included, that may well drop you into the ROM monitor, but it does not crash the machine in the way you implied. Andrew L. Duane (JOT-7) w:(408)366-4935 Motorola Microcomputer Design Center decvax!cg-atla!samsung!duane 10700 N. De Anza Boulevard uunet/ Cupertino, CA 95014 duane@samsung.com Only my cat shares my opinions, and she's Intel 80286 based.
andrew@frip.WV.TEK.COM (Andrew Klossner) (04/10/91)
[]
"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."
You still have to clean up any filth in the pipeline. For example, on
a demand-paged system, it's possible that a page fault coincided with
the interrupt. If the data exception bit is on in DMT0 (or is it DMT2?
.. they keep renumbering them), your interrupt handler is responsible
for handling the page fault -- you can't just return from interrupt.
I haven't seen a Unix system use "method 1," largely for this reason.
-=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]robertb@june.cs.washington.edu (Robert Bedichek) (04/11/91)
In article <2524@urbana.mcd.mot.com> aduane@urbana.mcd.mot.com (Andrew Duane) writes: >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. > >>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? > >I have seen some of the responses to this so far, and thought that it >would be appropriate for me to cast the single "yes" vote. > >I am doing interrupt and other locore work for the motorola MVME188QP >quad processor board. We have designed a set of "fast" interrupts that >are propagated from processor to processor to do hardware operations >such as updating the IEN enable masks. This requires no context to >be saved, and was designed around being very fast for the interrupted >processor, so we do it in about 20 instructions or so right at interrupt >time, before any saving or re-shadowing is done. At RTE from this, any >other pending exceptions will he handled normally. As Andrew Klossner pointed out, you do have to check for faulted transactions in the DMU and handle them. You could run for a while without doing this and not notice because for the bug to show up you would have to have one of your "fast" interrupts happen just when the interrupted processor was taking a page fault. Btw, I plan to use method #1 in an multiprocessor project that we are working on here at UW. Exceptions on the 88k don't have to be piggy if one doesn't mind keeping the FPU off and staying in assembly code and not being able to field interrupts (or any other exception) during the handler. Robert Bedichek robertb@cs.washington.edu