Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!husc6!encore!pinocchio.encore.com
From: jkenton@pinocchio.encore.com (Jeff Kenton)
Newsgroups: comp.sys.m88k
Subject: Re: Grabbing arithmetic overflow traps ?
Message-ID: <12148@encore.Encore.COM>
Date: 29 Jun 90 13:11:06 GMT
References: <9733@discus.technion.ac.il>
Sender: news@Encore.COM
Lines: 50

From article <9733@discus.technion.ac.il>, by devil@techunix.BITNET (Gil Tene):
> 
> 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.
> 

I don't think this is a bad idea at all (although I can imagine *bad*
implementation).  Kernel overhead is huge.  If you can turn overflow
exceptions into "fast traps" for your own procersses without changing
the semantics of overflow for others, go for it.

On the 88000, people have found lots of uses for "fast traps", where
you get into and out of the kernel without the full overhead.

*** WARNING:  *** Warning Ahead ***  WARNING ***

However, most fast trap implementations I have seen use real trap
instructions.  You can't.  Therefore, you have to be very careful
about the memory pipeline and the floating point pipeline.  If there
is anything in the data pipeline, you are probably better off going
into normal kernel processing (with the registers *exactly* right).
For the FP pipe, you probably have to keep it disabled throughout
your (short) procedure, since there is no good way to find out what's
in it (and pass that info to the kernel).  That means no FP instructions,
of course, and no multiply or divide.

*** RETRACTION ***

Maybe it is a *BAD* idea.  If you have kernel source and know exactly
what you're doing, it could certainly work, and be much faster.  But,
it may be scarier than I thought three paragraphs ago.

Good luck.

Questions? --> e-mail: jkenton@pinocchio.encore.com


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
		   ---  always at (617) 894-4508  ---
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -