🚀 go-pugleaf

Doug Merritt and I have been having a small sling-shot war over the
desirability of of various memory models. I have been contending that a single
addressing space is preferable, because it allows tasks to access each other's
space, while Doug has been claiming that separate addressing space is
preferable due to the protection features thus inherited.

But when we are comparing operating systems with different memory models, we
have to compare operating systems which offer the same other features. Doug
is comparing an operating system with virtual memory, memory protection and
separate addressing spaces to an operating system with virtual memory, no
memory protection and a single addressing space.

That is wrong. We have to compare operating systems which offer both virtual
memory and memory protection regardless of memory model. Let me
illustrate:

Doug Merritt <doug@xdos.uucp> writes in Message-ID: <367@xdos.UUCP>

> For real time programming, the performance advantage of shared address
> spaces makes them desirable, and hence the single address space model
> we have on the Amiga is a blessing. It is a mixed blessing nonetheless,
> since any malfunctioning program can bring down the whole machine.

You see? Doug is saying that a single program can bring down the whole machine.
Obviously he was talking about an operating system without memory protection.

> Sometimes this is because it has misused a hardware resource, something
> that a protected private address space model (adapted to the Amiga's
> demands) would not prevent.

Oops, so perhaps he does mean that the OS has memory protection. But now he
says that misusing a hardware resource can be fatal to a single address space
OS, but not to a separate address space OS. Can you see the reasons why? Can
you see that this is implementation dependent?

> But most of the time it's simple things,
> like not deallocating memory, or overwriting OS structures with a runaway
> pointer. These problems simply do not arise on systems with private
> address spaces, or even on systems with a single address space but
> each task limited to writing in the memory that belongs to it.

Whoa! Now he is comparing an operating system which has resource tracking with
one which does not. That is ridiculous. It is obvious that when memory
protection is implemented on the Amiga, resource tracking will have to be added
so that crashing programs may free up the requested resources. In a separate
address space operating system, resource tracking has to be implemented too,
and it is just as difficult to implement, if not more.

So at this point, let me compare AmigaOS 2.0 as I propose it, to that which
Doug suggests would be better.

Valentin's AmigaOS 2.0:

FEATURES:

1. Single addressing space.
2. Virtual memory.
3. Memory protection.
4. Resource tracking.

ADVANTAGES:

1. Fast context switches, fast message passing (no space copying)
2. Real-time response.
3. Allows tasks to monitor each other, to read (not write, unless allowed)
   each other's addressing space, to share code.

DISADVANTAGES:

1. Virtual memory fragmentation.
2. Limited total addressing space to 4 Gigabytes. (wow!)
2. Fixed-size stacks. Can be made variable by allowing separate address spaces
   for stacks from the main body. (A la (ICK) Unix.)
3. Fully compatible with old software. Code with Forbid() & Disable() has to be
   put in MEMF_LOCKED memory.


Doug's operating system:

FEATURES:

1. Multiple addressing spaces
2. Virtual memory
3. Memory protection
4. Resource tracking

DISADVANTAGES:

1. Slow context switches. Slow message passing. (requires MOVES instrucions)
2. No real-time response. Needs real-time 'extensions' which basically consists
   in implementing shared physical memory...
3. Does not allow shared code, no shared libraries. Can be 'extended' to allow
   these.
4. Does not allow programs to monitor each other. Needs special operating
   system primitives to allow debugging.
5. As compatible with current AmigaOS software as MS-DOS software is.

ADVANTAGES:

1. Provides each program with 4 Gigabytes of addressing space. Can be further
   extended into separate program and data spaces.
2. Layer operating systems on top of each other. Now you can run AmigaOS, Minix
   Unix, Uselessix and Boringix together *at the same time*. Wow! Always wanted
   to do that!

Now Doug has made a rather funny comment in a previous posting. You have to be
careful when analysing the implementation of any of these two memory models:

> Another strong disadvantage of a single address space model is that it
> has problems regarding addressing. Let's say I run two programs,
> say for the purpose of having two copies of the same chess program play
> against itself. The Amiga simply relocates each copy to a different
> piece of allocated memory (patches each process to address correctly
> relative to its load point). But once that's done, each must always reside
> in that particular piece of physical memory. This puts a severe restriction
> on virtual memory, since each time one of those tasks is run, the same
> physical ram must be freed again, which will often mean that whole
> processes will *have* to be swapped out, while if private address spaces
> were implemented, then we'd be free to put it anywhere in physical ram
> we want.
>
> Thus by asking for both virtual memory and for a single address space,
> you end up requiring the swapping that you said was such a bogus feature!

His error is pretty easy to catch if you though out how virtual memory is to
be implemented. You see, the virtual memory handler on a single address space
OS does not care what program is running in what memory. It merely swaps in and
out individual pages one-by-one. Full programs never have to be swapped out
entirely, just individual pages. This will become more obvious in a couple of
weeks.  :-)

Valentin
_________________________________________________________________________
"An  operating  system  without         Name:   Valentin Pepelea
 virtual memory is an operating         Phonet: (613) 231-7476 (New!)
 system without virtue."                Bitnet: 451061@Uottawa.bitnet
                                        Usenet: Use cunyvm.cuny.edu gate
         - Ancient Inca Proverb         Planet: 451061@acadvm1.UOttawa.CA