Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061
From: 451061@UOTTAWA.BITNET (Valentin Pepelea)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <8905270516.AA18668@jade.berkeley.edu>
Date: 26 May 89 21:53:08 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 65

Deven Corzine <deven@rpi.edu> writes in
Message-ID: <DEVEN.89May26034702@daniel.rpi.edu>

>  (Valentin Pepelea) writes:
>
>     Interrupt code might be called up by any task in the system. Thus
>     the Exec and the MMU will think that the code executed is part of
>     the calling task. If that code and its data can are not accessible
>     through the MMU by what the Exec thinks is the current task, you
>     get a priviledge violation error.
>
> Interrupt code is not "called up" by any task in the system.  Yes,
> interrupts can occur while any task is running.  But, there could be a
> separate MMU context for interrupts...  The problem does NOT lie with
> what *Exec* thinks the current task is, but with what the *MMU* is
> using for the current context.  It's not inconceivable to
> context-switch for interrupts, though the overhead may well be such as
> to make it impractical.

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.
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.

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.

> 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.

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.

> I stand by my statement.

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

> Deven

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