🚀 go-pugleaf

In article <8905270516.AA18668@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:

   Um, what I meant is that since the MMU is to be entirely controlled by the
   future Exec, then the MMU context and the current task context are the same.

That seems a rather unfounded assumption.  Yes, it's likely how it
might be implemented, just because of C-A's passion for ultimate speed
except when scanning directories...  But this is not a given.

   Due to the way Amiga interrupts are managed, it would be rather uncomfortable
   to play with the MMU for interrupt processing. The rate of interrupt arrivals
   on real-time operating systems such as the Amiga's can be overwhelming. Trying
   to load the MMU with the proper root pointer can delay interrupt processing
   considerable. Thus since the root pointer can not be changed, you better
   declare your code and variables as MEMF_PUBLIC.

Quite so.  But impractical as it may be, it remains a possible
approach.

   Not that a simple way to avoid this is to have a translation table that gives
   full privilege to code running in Supervisor mode, because user tasks are not
   supposed to go into supervisor mode all by themselves. An option to consider,
   although it is not what I consider ideal.

Less than ideal, but a quick and easy way out...

   > Arguments can certainly be entertained by both sides, but the fact
   > remains that Exec was designed using the model of a *single* address
   > space for all tasks, with any task being able to access the memory of
   > *any* task.

   You are mixing up two concepts here. Yes the Exec was designed to use the
   single address space model. Hoever that does not imply that tasks should be
   allowed to access each other's memory. The only reason current Minis and
   Mainframes, give tasks their own address space is because two decades ago,
   processors could access only a limited amount of ram. (say 64K) Thus for
   multi-tasking, the computer would swap the entire programs in and out of that
   same physical space at ever context switch. Even Unix uses this *poor* memory
   model, indeed it was first develloped for the PDP-11, which had a 64K
   instruction space and 64K data space.

I'm not mixing up the concepts.  I mentioned them together, but
they're not interdependent.  The single address space isn't very
important (except when it comes to things like paging executables to a
file) but the assumption that all memory is publicly accessible is
rather ingrained.  The message-passing mechanism assumes it, and it is
relied on heavily by all parts of the system for proper operation, and
the lack of memory protection is relied on to keep the overhead low,
by avoiding copying.  The single address space is assumed also, but
that would not change by addition of VM.  Hence, my statement that VM
should be easier to _integrate_ with the system than memory
protection...  without breaking everything.

[The Unix memory model has changed many times.]

   If they had processors able to access 4 Gigabytes of physical ram, then Unix
   too would enjoy the superior functionality available in single-addressing
   space operating systems.

"superior functionality"?  What is inherently superior about a single
address space?

   > I stand by my statement.

   I stand by the model of the ideal real-time message-based operating system.

Exec is pretty good, but I wouldn't say ideal.

Deven
--
shadow@[128.113.10.2]   <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu>  2346 15th St.    Pi-Rho America
deven@rpitsmts.bitnet   <userfxb6@rpitsmts>   Troy, NY 12180-2306  <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.