Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!att!chinet!mcdchg!mcdphx!estinc!fnf
From: fnf@estinc.UUCP (Fred Fish)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <96@estinc.UUCP>
Date: 11 Jun 89 17:26:50 GMT
References: <8906030123.AA14671@jade.berkeley.edu> <7060@cbmvax.UUCP>
Reply-To: fnf@estinc.UUCP (Fred Fish)
Organization: Enhanced Software Technologies, Inc.
Lines: 31

In article <7060@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>I agree, there's nothing inherently safer about systems with private address
>spaces vs. those with a single address space.  Equal protection can be added
>to each; the MMU doesn't care.  Most of the single-space problems we have in
>the Amiga, like overwriting structures, etc. are purely a problem because we
>don't have protection.  Either protected system would drop you out with an
>access violation; the memory model has nothing to do with it.

I would agree with only one minor caveat that pertains to repeatability.
If each process has it's own private address space that always starts at
some fixed address (preferably NOT 0), then each execution of a program
should give identically behavior with the same inputs, regardless of what
else the system might be doing.  With a scatter loading system, where the
addresses may change from one run to the next, certain classes of bugs may
be VERY hard to reproduce.  And if you can't reproduce a bug, it is a royal
pain to find.

Thus, on a private address space machine, you can go through extensive testing
and have some level of confidence that any lurking bugs have been squashed.
On a scatter loaded machine you can have an innocuous bug that never shows
up in testing, but bites the first time you get loaded a couple of megabytes
further up in the address space (or maybe even 4 bytes).  Anyone who has ever
ported Unix to a new hardware configuration is familiar with the problem of
programs that break when you run them on your new wizzbang hardware that
maps text at 0x100000, rather than 0x1000 (or worse, 0x0) where it was on
your last machine.
 
-Fred
-- 
# Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284,  USA
# 1-602-491-0048           asuvax!{nud,mcdphx}!estinc!fnf