Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!littlei!zeus!hays From: hays@zeus.hf.intel.com (hays) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <405@zeus.hf.intel.com> Date: 2 Jun 89 21:54:31 GMT References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <1RcY6x#64Zq3Y=news@anise.acc.com> <26204@ames.arc.nasa.gov> Reply-To: hays@farside.UUCP (Kirk Hays) Organization: Intel OMSO, Hillsboro, OR Lines: 22 In article <26204@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >Last week I saw an ad for a real time version >of Unix with a guaranteed response time (switch to kernel to high priority >process) of 5 milliseconds. Hugh is absolutely right in his response here - you must design for your environment. A guaranteed task switch of 5 milliseconds is *soft* real time, but is still impressive for a real time Unix. I have worked on a *hard* real time kernel for the 386 (iRMK, from Intel) where we designed for a 50 uS maximum guaranteed interrupt latency, and a 5 uS maximum guaranteed task switch (at 16 MHz). Not easy, but three orders of magnitude faster than the Unix mentioned above - and with its own market niche. The point? Design for your environment - chips for UNIX should have large register files, real time chips should have small register files, and compromises will be made for many successful products. ----- Kirk Hays -- "I'm the NRA!"