Path: utzoo!utgpu!watmath!clyde!att!mtuxo!mtgzy!mtgzz!dam
From: dam@mtgzz.att.com (d.a.morano)
Newsgroups: comp.arch
Subject: Re: Intel/MIPS Dhrystone ratio
Summary: fork process
Message-ID: <5035@mtgzz.att.com>
Date: 22 Mar 89 16:41:57 GMT
References: <1552@vicom.COM> <28200290@mcdurb> <24929@amdcad.AMD.COM>
Organization: AT&T, Middletown NJ
Lines: 26

In article <24929@amdcad.AMD.COM>, rpw3@amdcad.AMD.COM (Rob Warnock) writes:
> 
> [Tutorial alert. Many of you know this already. But it's worth saying once
> or twice a decade, and I haven't heard it lately, so here goes...]
> 
> As has been done by many of us on a variety of machines, a useful interrupt
> software "style" (good on many CISCs as well as RISCs) seems to be to split
> interrupt handlers into a "first-level"/hardware-oriented/assembly-language
> section, and a "second-level"/software-oriented/C-language part, with the
> following characteristics:
> 
>	[many characteristics of the above style deleted]

As you probably know, you have described in essence exactly what DEC did
for their RSX-11M and VMS operating systems 15 or so years ago.  DEC calls 
their second level handlers 'fork processes'.  These second level fork 
processes could execute partially in true hardware interrupt time and 
partially in scheduled light weight process time after the hardware 
interrupt has been dismissed.  The amount of time spent in either mode is
programmed in the fork process by using dispatching and light weight
scheduling primitives.  This style, as you have called it, does have the
benefits that you have sited.  This approach to interrupt handling 
better positions these OSes for hardware oriented time critical applications.
Of course, DEC would code both portions of their handlers in assembly.

Dave Morano	AT&T Bell Laboratories