Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!seismo!harvard!talcott!panda!genrad!decvax!decwrl!glacier!mips!kim
From: kim@mips.UUCP (Kim DeVaughn)
Newsgroups: net.micro.amiga
Subject: Re: Memory Management w/o MMU"
Message-ID: <241@mips.UUCP>
Date: Mon, 25-Nov-85 15:11:16 EST
Article-I.D.: mips.241
Posted: Mon Nov 25 15:11:16 1985
Date-Received: Fri, 29-Nov-85 08:02:53 EST
References: <370@caip.RUTGERS.EDU> <371@sdcc13.UUCP>
Organization: mips ... where RISC is a way of life
Lines: 28

> You know, I am getting sick of all these 'how do you do
> multi-tasking without an MMU' questions.
> 
> GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
> 
> THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.

Larry -

True.  *IF* the applications you're running are "well-behaved" ... which
is not what one typically finds in a development environment.  

Or, in a production environment, ever try to find that one bug that crashes
the machine and shows up only on odd Thursdays, and then only if you're
running the payroll program and exactly 3 people are running the Foo editor,
and then ... well, you get the idea;  which piece of code do you blame/debug?

At least h/w memory management can *help* you isolate such problems.  No,
MMU's won't eliminate them, but they can at least isolate buggy code to a
certain degree.

/kim
-- 

UUCP:  {decvax,ucbvax,ihnp4}!decwrl!mips!kim
DDD:   415-960-1200
USPS:  MIPS Computer Systems Inc,  1330 Charleston Rd,  Mt View, CA 94043