Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site othervax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-crg!seismo!cmcl2!philabs!micomvax!othervax!ray
From: ray@othervax.UUCP (Raymond D. Dunn)
Newsgroups: net.micro.amiga
Subject: Re: Memory Management w/o MMU
Message-ID: <728@othervax.UUCP>
Date: Wed, 27-Nov-85 15:38:14 EST
Article-I.D.: othervax.728
Posted: Wed Nov 27 15:38:14 1985
Date-Received: Fri, 29-Nov-85 10:52:43 EST
References: <370@caip.RUTGERS.EDU> <371@sdcc13.UUCP>
Reply-To: ray@othervax.UUCP (Raymond D. Dunn)
Organization: Philips Information Systems - St. Laurent  P.Q., Canada
Lines: 49

In article <371@sdcc13.UUCP> ec150fcy@sdcc13.UUCP (Joseph McCaughey) writes:
>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 J. McCaughey

Sorry Larry (or is it Joseph), whether you're sick or not, you got it wrong
too!

Its even simpler than that, you need no hardware assistance what so ever!

I have written two fairly complex (16K instruction) closed environment
multi-user, multi-tasking, specific application systems with no hardware
assistance at all!  Only some status registers to *POLL*!  Just to complicate
matters, the machine had a 16-level subroutine stack which could not be
accessed by software (only the call/return instructions affected the stack)!

To be specific, the machines were newspaper editorial front end
"concentrators" supporting all text editing/host communications for 8
terminals on each concentrator.  Each terminal could invoke up to 3
simultaneous tasks.  Imagine - 8 keyboards, and a bi-directional host comms
port, - all without interrupts - and a word-processing type application
handling up to 24 tasks simultaneously.

The processor was a discrete TTL logic microprocessor - you know the sort -
setting memory address registers, latching the memory onto the bus, strobing
the data-bus through the ALU etc. (programmed in "assembler" of course) -
Ahhh.. the good old days!

Seriously, this is not a question of what is necessary, only what is best.
Of course memory protection and (some type of) MMU is best (even if it is
just a set of base/range registers).

In an open system which can run applications and software development
simultaneously, it can be considered necessary.

In a closed environment running trusted software, nothing is necessary, not
even a real time clock (though it would have helped a lot - sigh), as
cpu-bound software can be trusted to periodically call the (de)scheduler-I/O
poller.  In this sort of environment there is no difference between a
multi-tasking system and a straight application program - is one procedure
protected from having its workspace splatted on by another procedure?

Ray Dunn.   ..philabs!micomvax!othervax!ray