Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!percy!data!kend From: kend@data.UUCP (Ken Dickey) Newsgroups: comp.arch Subject: Re: Interrupts in user space; Lightweight Traps Message-ID: <413@data.UUCP> Date: 25 Sep 90 19:03:34 GMT References: <12738@encore.Encore.COM> Organization: Microcosm, Beaverton, OR Lines: 43 jkenton@pinocchio.encore.com (Jeff Kenton) writes: >With the recent RISC chips (88000, MIPS and i860 come to mind) the overhead >of getting the machine state safely saved away in the low level exception >code is substantial. You have to do this anyway before you can hand off >control to the user program "without going into the OS kernel", so the >savings don't amount to much. Let's talk about the next generation... There is another aspect of this which needs attention by HW implementors. There is a desire for fast computing. There is a desire for reasonable models of computation. The problem is that all traps (e.g. on the 88k) are "heavyweight" in the sense that for reasons mentioned above, OS designers don't give compiler/runtime implementors control directly. Typically, all traps get reflected through the O.S. Divide by zero and other "show stoppers" can take a long time to service, but who cares? Such exceptions reflect to a runtime handler (which may be a debugger). The real pain with heavyweight traps is trying to give reasonable performance with reasonable models. As an example, if one gets an integer numeric overflow, some languages change representations and go to bignums. It is a real pain (not to mention performance loss and code expansion) to implement the guard bits and checks almost everywhere because the runtime system can't afford the time to take a heavyweight trap. The same situation applies whether checking tagged data on polymorphic operation dispatch as in using operations on logical entities like numbers which have multiple representations. I think that the thing to concentrate on is design of HW architectures which support the above so that there are a set of "lightweight traps" which can be safely reflected to the runtime system. This could lead to a large savings in code size. I still hear "C only needs fixnums and floats, Unix only core dumps so we don't have to do better." C and Unix are in the class 20 year old technologies (circa 1972). A more general and mature view of OS and language implementation technologies than this is definitely called for. [Of course none of us would say that 8^]! -Ken Dickey kend@data.uucp