Path: utzoo!attcan!uunet!wuarchive!usc!ucsd!ucbvax!techunix.BITNET!devil From: devil@techunix.BITNET (Gil Tene) Newsgroups: comp.sys.m88k Subject: Re: Grabbing arithmetic overflow traps ? Message-ID: <9733@discus.technion.ac.il> Date: 28 Jun 90 18:35:08 GMT References: <9724@discus.technion.ac.il> <3418@oakhill.UUCP> <1990Jun27.173213.8250@dg-rtp.dg.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: devil%techunix.bitnet@jade.berkeley.edu (Gil Tene) Organization: Technion, Israel Inst. Tech., Haifa Israel Lines: 45 Well, I am the guy who originally started this question running. Actually, I don't need to have the C compiler generate instructions which will cause overflows, I generate the binary code myself, this is part of the application. I DO NEED the overflow detection to be FAST, or more importantly, minimize overhead. I want to thank all the people who replied, and the basics were the same from everyone: Integer and floating point overflows both generate a SIGFPE signal in the kernel, all I have to do is provide a handler. (I really didn't know this...). Now for the followup question: I can handle the overflows now, but signal overhead is HUGE for what I am doing, since it includes a context switch and all the kernel overhead. I want something that is FAST, since I may expect more than 5000 overflows a second. My application is simulating a computer model, and must provide the same functionality as the simulated machine. This includes overflow, and means that the overflow flag of the simulated machine must be set on every overflow that occurs, whether it is checked or not. I would like opinions on the following "bad-programming" idea: Interpose the kernel's overflow-trap handling routine with my own routine. My routine will check the current context, to make sure it is the same as the simualting process's. If the context is different, the kernel's overflow routine is called, otherwise, my routine handles the overflow, and simulates it's behaviour on the simulated machine. This would mean I need to allocate kernel memory space, stick my routine in it, and handle the trap interposing. I know this is "bad-programming", but it is much FASTER then letting the kernel do the work. Anyone have any suggestions/observations ? (This is all done on an Aviion AV300, running DG/UX 4.20, BTW.) AdvThanks, Gil. -- -------------------------------------------------------------------- | Gil Tene "Some days it just doesn't pay | | devil@techunix.technion.ac.il to go to sleep in the morning." | --------------------------------------------------------------------