bvs@light.uucp (Bakul Shah) (05/14/88)
>> ... 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? > >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". On a RISC processor the overhead to dispatch a user mode trap handler can be sufficiently low to make their use practical. This is certainly true of the AMD 29000 processor. Example: supervisor_handler_N: mfsr tpc, PC1 ; save the old PC in tpc mtsr PC1, utrap ; setup PC to return to user_handler_N add tmp, utrap, 4 ; mtsr PC0, tmp ; need two PCs on this pipelined machine iret ; interrupt return Here register utrap has the address of user_handler_N, PC1 and PC0 are special registers that contain address of the instruction after the trapped instruction and the next instruction after that. Trap N is routed by hardware to supervisor_handler_N, which sets things up so that interrupt return is to user_handler_N. user_handler_N: ... jmpi tpc The user mode handler does whatever is necessary and finally jumps to the instruction after the trapped instruction. This scheme takes 5 more instructions compared to a supervisor mode trap handler for the same thing. Actually, it turns out this is the *most* efficient way of handling certain kinds of traps on the 29000. When any trap is taken, the virtual memory mapping is turned off (necessary since traps don't nest on the 29k). So if you want to use VM in a handler and don't need access to any supervisor-only facility, you are better off with user mode handlers than messing with various registers to do VM operations on user's behalf. ---- Bakul Shah <..!{ucbvax,sun}!amdcad!light!bvs> PS: I have lied a little to get the main point across. Interested people can read the user's maunal for details on the 29k.
meissner@xyzzy.UUCP (Michael Meissner) (05/18/88)
In article <1988May12.162207.16764@utzoo.uucp> Henry Spenser writes: | > ... 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? | | 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". The Data General MV series of computers traps many of the fault conditions (overflow, underflow, etc.) directly into user code. In our UNIX implementation, the language runtimes commonly intercept these faults and turn them into signals via kill, but I've written programs targeted for the machine that swaps the default handlers with my own. The machine used to trap segmentation violations (as opposed to normal page faults) to user mode as well, but we had to retrofit trapping to the kernel because we wanted to conform to the Government security guidelines (C2 I think), which mandate that any attempt to read/write protected code like the kernel be logged. Nowadays, both the propriatary and the native UNIX kernels catch segmentation errors, and call the user handler, since some of our software depends on using their own handlers. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net