Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!rpi!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: End-of-buffer interrupt instruction Message-ID: Date: 17 Sep 90 16:19:44 GMT References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> <2128@key.COM> <2567@l.cc.purdue.edu> Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 37 In-Reply-To: cik@l.cc.purdue.edu's message of 17 Sep 90 12:52:14 GMT >Let me clarify the situation. There are natural situations arising in >Monte Carlo where one cannot predict when a buffer will empty. Steps >can be taken to make it rare. Therefore, the "natural" way to want to >handle this is to have an interrupt, or exception if you prefer, when >this does happen. Is there any good reason why the user cannot set up >conditions for interrupts, and handling procedures for them? I believe >that some setups allow for these without necessarily invoking the kernel. > >The advantage of an interrupt procedure over a test each time is that >the interrupt is rare, and does not have the costs of the test when it >is not invoked. It is likely to lengthen the instruction, however. On >the other hand, an interrupt certainly has much higher costs than the >test when it does cut in. I think I understand. It's not so much a block copy, as a read the next item, where the reads are scattered all over. I frequently encounter situations like this when I am instrumenting code, eg. recording events into a trace buffer. The branches to detect buffer overflow are often much more expensive than the record of the event itself. In such circumstances I often want to ensure that my buffers are page aligned, and that an access to one element past the end of the buffer will cause a page fault that I can handle. I've only done this once, because I'm not always in the kernel. Conceivably MACH's memory handling facilities could let you do this. Recently, I encountered a situation where I did not want to trap on trace buffer overflow, but only to silently go on. (Ie. stop recording but do not disturb the rest of the computation). Mapping many virtual pages past the end of my buffer to the same physical page would have accomplished this - even better would have been a /dev/null page type. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]