deven@rpi.edu (Deven Corzine) (05/18/89)
For those clamoring for a MEMF_PHYSICAL memory requirements flag -- is this not what MEMF_PUBLIC really is? The RKM isn't so clear, but the "Amiga Programmer's Handbook" (Sybex) describes the flag as "memory which can not be swapped out, mapped or otherwise made nonaddressable." In other words, add to <exec/memory.h>: #define MEMF_PHYSICAL MEMF_PUBLIC and have a blast... If there IS some other distinction, do tell. [perhaps it specifies physical memory which is publically accessible?] Anyway, a thought. 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.
thomas@cbmvax.UUCP (Dave Thomas QA) (05/18/89)
In article <DEVEN.89May18024329@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > > For those clamoring for a MEMF_PHYSICAL memory requirements flag -- is > this not what MEMF_PUBLIC really is? The RKM isn't so clear, but the > "Amiga Programmer's Handbook" (Sybex) describes the flag as "memory > which can not be swapped out, mapped or otherwise made > nonaddressable." In other words, add to <exec/memory.h>: > > #define MEMF_PHYSICAL MEMF_PUBLIC > > and have a blast... > > If there IS some other distinction, do tell. [perhaps it specifies > physical memory which is publically accessible?] > Deven MEMF_PUBLIC involves memory protection if/when it is ever implemented. Memory which is MEMF_PUBLIC is accessible to multiple tasks. Non MEMF_PUBLIC memory is accessible only to your own task. Of course, currently, MEMF_PUBLIC is not meaningful; all memory is MEMF_PUBLIC. This has nothing to do with virtual memory. MEMF_PHYSICAL would specify memory which must not be swapped out, but this says nothing about accessibility to other tasks. Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/18/89)
:For those clamoring for a MEMF_PHYSICAL memory requirements flag -- is :this not what MEMF_PUBLIC really is? The RKM isn't so clear, but the :"Amiga Programmer's Handbook" (Sybex) describes the flag as "memory :which can not be swapped out, mapped or otherwise made :nonaddressable." In other words, add to <exec/memory.h>: MEMF_PUBLIC is so badly defined that most people use it incorrectly... either that or allocate all of their memory MEMF_PUBLIC. It has essentially become a random flag and as such should be phased out (with the bit eternally reserved to mean nothing). -Matt
deven@rpi.edu (Deven Corzine) (05/19/89)
In article <6914@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes:
MEMF_PUBLIC involves memory protection if/when it is ever
implemented. Memory which is MEMF_PUBLIC is accessible to multiple
tasks. Non MEMF_PUBLIC memory is accessible only to your own task.
Of course, currently, MEMF_PUBLIC is not meaningful; all memory is
MEMF_PUBLIC. This has nothing to do with virtual memory.
MEMF_PHYSICAL would specify memory which must not be swapped out, but
this says nothing about accessibility to other tasks.
The name MEMF_PUBLIC clearly implies a relation to memory protection
(more precisely, lack thereof) yet it isn't so clearly defined.
Clearly, it implies that other tasks can access the memory, (and that
much the RKM clearly states) but what isn't clear is what effect, if
any, such a designation should mean with regards to virtual memory.
It COULD be interpreted as "any task can access the memory at any
time, so it must always be in memory." Of course, if a task accesses
the memory, it can be just swapped in, so that's not reason enough.
However, if you consider interrupts, the argument becomes more viable.
You can't expect the memory page to be swapped in if an interrupt
needs to access the memory; it takes too long. And all interrupt code
and data is supposed to be in MEMF_PUBLIC memory. (irregardless of
the fact that the flag is currently meaningless.) This argues that
MEMF_PUBLIC memory, beyond being publicly accessible, must also be
locked in memory, in the event that an interrupt might access it. If
you're saying that there would be an MEMF_PUBLIC flag and an
MEMF_PHYSICAL flag, totally unrelated, then how do you define the case
of interrupt code in or accessing virtual memory?
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.deven@rpi.edu (Deven Corzine) (05/19/89)
In article <8905181642.AA07593@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
MEMF_PUBLIC is so badly defined that most people use it
incorrectly... either that or allocate all of their memory
MEMF_PUBLIC. It has essentially become a random flag and as such
should be phased out (with the bit eternally reserved to mean
nothing).
Indeed. Certainly a thought to consider. But, that will annoy many
people who've been including it all this time "for future
compatibility"... :-)
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.bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (05/19/89)
In article <DEVEN.89May19053755@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: >In article <6914@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: > > MEMF_PUBLIC involves memory protection if/when it is ever > implemented. Memory which is MEMF_PUBLIC is accessible to multiple > tasks. Non MEMF_PUBLIC memory is accessible only to your own task. > Of course, currently, MEMF_PUBLIC is not meaningful; all memory is > MEMF_PUBLIC. This has nothing to do with virtual memory. > MEMF_PHYSICAL would specify memory which must not be swapped out, but > this says nothing about accessibility to other tasks. > >... This argues that >MEMF_PUBLIC memory, beyond being publicly accessible, must also be >locked in memory, in the event that an interrupt might access it. If >you're saying that there would be an MEMF_PUBLIC flag and an >MEMF_PHYSICAL flag, totally unrelated, then how do you define the case >of interrupt code in or accessing virtual memory? Well, much like the rest of the MEMF flags, what is the matter with MEMF_PUBLIC | MEMF_PHYSICAL Why do you want to mix the semantics? Keep it simple, etc etc bla bla bal I support the notion put forward by Valentin ... if you are going to add virtual memory to the Amiga, why not do it right the first time? Have it break current stuff ... doesn't bother me! Of course, that's just my preference. I realize from the marketing point of view that's BAD. *sigh* I want a memory protected, virtual memory Amiga. It would be sooooo nice. Blair, waiting patiently for that sort of machine! ( it's not like I'll have money till the end of the summer anyway!! ) :-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-///-= = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} \\\/// = = now appearing at the Computer Graphics Lab, U of Waterloo! \XX/ = = "Don't be mean ... remember, no matter where you go, there you are." BBanzai=
dwi@manta.NOSC.MIL (Steve Stamper) (05/19/89)
MEMF_PUBLIC descriptions on previous messages bring up an important point. Is any data structure I create that will be accessible by the custom hardwre (GELS for example) suppose to be in MEMF_PUBLIC? I think I have been using MEMF_PUBLIC basically for on IO Blocks to and from devices, maybe not even that all of the time, but I am reasonably sure that I used it for that all of the time. I may well be one of the people using MEMF_PUBLIC incorrectly but I was never 100% sure of what system structures had to be in MEMF_PUBLIC. -Roger
thomas@cbmvax.UUCP (Dave Thomas QA) (05/22/89)
In article <DEVEN.89May19053755@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > The name MEMF_PUBLIC clearly implies a relation to memory protection > (more precisely, lack thereof) yet it isn't so clearly defined. > Clearly, it implies that other tasks can access the memory, (and that > much the RKM clearly states) but what isn't clear is what effect, if > any, such a designation should mean with regards to virtual memory. It has no effect on virtual memory. Public memory is simply memory accessible to all tasks. It has nothing to do with virtual memory at all. There is absolutely no reason why public memory could not be virtual memory. > It COULD be interpreted as "any task can access the memory at any > time, so it must always be in memory." It could, but that's complicating the definition needlessly. > Of course, if a task accesses > the memory, it can be just swapped in, so that's not reason enough. > However, if you consider interrupts, the argument becomes more viable. > You can't expect the memory page to be swapped in if an interrupt > needs to access the memory; it takes too long. And all interrupt code > and data is supposed to be in MEMF_PUBLIC memory. (irregardless of > the fact that the flag is currently meaningless.) This argues that > MEMF_PUBLIC memory, beyond being publicly accessible, must also be > locked in memory, in the event that an interrupt might access it. If > you're saying that there would be an MEMF_PUBLIC flag and an > MEMF_PHYSICAL flag, totally unrelated, then how do you define the case > of interrupt code in or accessing virtual memory? Interrupt code MUST be in physical memory since interrupts must be serviced in a timely fashion. Also, interrupts on the Amiga do not really execute as part of any task and are in supervisor mode. Memory protection need not apply to them. Try to keep the concepts of memory protection and virtual memory separate in your mind. They really are two different animals. While it is true that systems which implement usually implement the other, it is not always the case. Memory protection is going to be very difficult to implement on the Amiga without breaking 99% of the programs out there, but virtual memory without protection can probably be done with much less impact on the software base. > Deven Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/23/89)
Dave Thomas QA <thomas@cbmvax.uucp> writes in Message-ID: <6943@cbmvax.UUCP> > Memory protection is going to be very difficult to implement on the > Amiga without breaking 99% of the programs out there, but virtual memory > without protection can probably be done with much less impact on the > software base. Actually it is the other way around. Virtual memory will cause many programs to break because they mishandle critical sections using Forbid()/Disable(). Memory protection may cause them to break only if they try to access non MEMF_PUBLIC memory, but that is really easy to fix. If that happens, simply pop up a requester saying "Task xxx tried to write on memory belonging to task yyy". Then offer gadgets with the following functions: 1. Allow task xxx to overwrite any memory belonging to task yyy. 2. Allow task xxx to overwrite any memory. 3. Kill task xxx. 4. Guru. The nice thing about this solution is that it is fully backwardly compatible with old software. But here I have to point out that memory protection can not be implemented fully to allow recovery in 100% of cases. The problems we are faced with is how do we protect MEMF_CHIP memory, which may be modified by the coprocessors. And how about the BFFxxx address locations? These are examples, there is a little more to care about. I better not mention the lack of resource tracking and the problems therefore incurred. But a nice thing about implementing memory protection is that it can be implemented in stages, each offering better protection and recovery thqan the previous. Memory protection, unlike virtual memory, can only be done by CBM staff with full access to the OS sources. The memory allocation routines have to be modified to allot page-aligned blocks of memory, the loader has to be modified to place the segments properly in in the different types of memory, etc. One nice thing about memory protection implementation 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
thomas@cbmvax.UUCP (Dave Thomas QA) (05/23/89)
In article <8905222148.AA05879@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > > Dave Thomas QA <thomas@cbmvax.uucp> writes in Message-ID: <6943@cbmvax.UUCP> > > > Memory protection is going to be very difficult to implement on the > > Amiga without breaking 99% of the programs out there, but virtual memory > > without protection can probably be done with much less impact on the > > software base. > > Actually it is the other way around. Virtual memory will cause many programs to > break because they mishandle critical sections using Forbid()/Disable(). Memory > protection may cause them to break only if they try to access non MEMF_PUBLIC > memory, but that is really easy to fix. If that happens, simply pop up a > requester saying "Task xxx tried to write on memory belonging to task yyy". > Then offer gadgets with the following functions: > > 1. Allow task xxx to overwrite any memory belonging to task yyy. > 2. Allow task xxx to overwrite any memory. > 3. Kill task xxx. > 4. Guru. > > Valentin Your solution would probably work, but the sheer number of programs which do not properly ask for MEMF_PUBLIC would cause this requester to show up quite frequently. Think of the number of programs which have gadget and menu structures compiled into their code. These data hunks should not be MEMF_PUBLIC (or else there is not much use in having memory protection) yet Intuition needs to access (both read and write) them. How many programs have IOStdReq's declared as local variables instead of allocating them dynamically? I don't think having a requester pop up every time I try to pull down a menu is going to be an acceptable solution. Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/24/89)
Dave Thomas QA <thomas@cbmvax.uucp> writes in Message-ID: <6955@cbmvax.UUCP>
- In article <8905222148.AA05879@jade.berkeley.edu> 451061@UOTTAWA.BITNET
- (Valentin Pepelea) writes:
- > If that happens, simply pop up a
- > requester saying "Task xxx tried to write on memory belonging to task yyy".
- > Then offer gadgets with the following functions:
- >
- > 1. Allow task xxx to overwrite any memory belonging to task yyy.
- > 2. Allow task xxx to overwrite any memory.
- > 3. Kill task xxx.
- > 4. Guru.
-
- Your solution would probably work, but the sheer number of programs which
- do not properly ask for MEMF_PUBLIC would cause this requester to show up
- quite frequently.
- ...
- I don't think having a requester pop up every time I try to pull down a
- menu is going to be an acceptable solution.
Oops, I think I did not make myself clear enough. Let me put it like this:
If a task xxxx tries to access memory belonging to task yyyy, then a request
will pop up displaying "Task xxxx tried to write in task's yyyy memory". A
list of gadgets will offer the following functions:
1. Allow task xxxx to write in task's yyyy memory only this time.
2. Allow task xxxx to write in system memory only this time.
3. Allow task xxxx to write in task's yyyy memory always from now on.
4. Allow task xxxx to write in system memory always from now on.
5. Kill task xxxx.
6. Guru.
Heh! Still 100% backwardly compatible. We should remember that yyyy's memory
is by default readable and only writes are initially inhibited. Furthermore,
we should remember that CBM has already set the proper rules clearly on where
MEMF_PUBLIC is required. Unlike for virtual memory, devellopers would not be
allowed to cry wolf on this one.
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.CAdeven@rpi.edu (Deven Corzine) (05/24/89)
In article <6943@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: In article <DEVEN.89May19053755@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > The name MEMF_PUBLIC clearly implies a relation to memory protection > (more precisely, lack thereof) yet it isn't so clearly defined. > Clearly, it implies that other tasks can access the memory, (and that > much the RKM clearly states) but what isn't clear is what effect, if > any, such a designation should mean with regards to virtual memory. It has no effect on virtual memory. Public memory is simply memory accessible to all tasks. It has nothing to do with virtual memory at all. There is absolutely no reason why public memory could not be virtual memory. I understand completely. I simply passed along a claim this book made, and as such, felt compelled to at least TRY to argue the (undeniably weak) case for their position. > It COULD be interpreted as "any task can access the memory at any > time, so it must always be in memory." It could, but that's complicating the definition needlessly. Obviously, but it's how they seem to have interpreted it. Interrupt code MUST be in physical memory since interrupts must be serviced in a timely fashion. Also, interrupts on the Amiga do not really execute as part of any task and are in supervisor mode. Memory protection need not apply to them. Fine. But the RKM's say interrupt code and data MUST be in MEMF_PUBLIC memory. Why? Try to keep the concepts of memory protection and virtual memory separate in your mind. They really are two different animals. While it is true that systems which implement usually implement the other, it is not always the case. Memory protection is going to be very difficult to implement on the Amiga without breaking 99% of the programs out there, but virtual memory without protection can probably be done with much less impact on the software base. I fully understand the distinction between memory protection and virtual memory. I was just arguing a case which was lost from the start. And yes, virtual memory will have far less damaging effects than memory protection, with the design of the operating system -- the message passing mechanism, in particular. But that wasn't the point. Regardless, I give up. It wasn't MY idea in the first place, and I thought it was stupid, also. I simply passed it along for whatever (small) value it might have. Geez. 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.
thomas@cbmvax.UUCP (Dave Thomas QA) (05/24/89)
In article <DEVEN.89May24025106@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > I wrote: > Interrupt code MUST be in physical memory since interrupts must be serviced > in a timely fashion. Also, interrupts on the Amiga do not really execute as > part of any task and are in supervisor mode. Memory protection need not > apply to them. > > Fine. But the RKM's say interrupt code and data MUST be in > MEMF_PUBLIC memory. Why? I don't know, but MEMF_PUBLIC has never been defined too clearly since it has never done anything. > Regardless, I give up. It wasn't MY idea in the first place, and I > thought it was stupid, also. I simply passed it along for whatever > (small) value it might have. > > Geez. > > Deven Sorry if I sounded harsh in my reply, I just wanted to make sure that all the issues were understood. That's what the net is about anyway. It allows us to toss around ideas and see where they go. I've enjoyed this thread tremendously! Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
deven@rpi.edu (Deven Corzine) (05/25/89)
In article <6966@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: In article <DEVEN.89May24025106@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > Fine. But the RKM's say interrupt code and data MUST be in > MEMF_PUBLIC memory. Why? I don't know, but MEMF_PUBLIC has never been defined too clearly since it has never done anything. Quite so. Perhaps, as Matt suggested, it should indeed be done away with. > Regardless, I give up. It wasn't MY idea in the first place, and I > thought it was stupid, also. I simply passed it along for whatever > (small) value it might have. Sorry if I sounded harsh in my reply, I just wanted to make sure that all the issues were understood. I understood immediately. That book misinterpreted. Can't ever believe what you read. *sigh* That's what the net is about anyway. It allows us to toss around ideas and see where they go. True, but this one got tossed around too much to be worthwhile. A simple clarafication would have done well enough. I've enjoyed this thread tremendously! I haven't. If I'm going to be flamed or attacked for something I post, I'd rather it be for MY ideas -- those I can usually defend adequately. And modify when valid objections are raised. On the other hand, I *did* enjoy the thread with Randell (mostly) about "Unix V7 functionality under (or along with) AmigaDOS?"... 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.
pl@etana.tut.fi (Lehtinen Pertti) (05/25/89)
From article <DEVEN.89May24182715@daniel.rpi.edu>, by deven@rpi.edu (Deven Corzine): > In article <6966@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: > > In article <DEVEN.89May24025106@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: > > Fine. But the RKM's say interrupt code and data MUST be in > > MEMF_PUBLIC memory. Why? > > I don't know, but MEMF_PUBLIC has never been defined too clearly since it > has never done anything. > I have always thought that idea behind MEMF_PUBLIC is to provide some compatibility with MMU-supported multitasking. I protected multitasking systems (like UNIX) every process has a address space of its own, and this address space lives and dies with process ( and also swaps to disk). Other processes have no access into this space, so if we want to install some code (or data) which is 'outside' this protected address space, we have declare it someway. In this case the method would be MEMF_PUBLIC. Unfortunately other parts of Amiga system seem to fight against this clean idea, but ... And to talk about virtual memory. I think that one method to provide some virtuality to amiga is the way how it is provided in Acorn's (ARM) memory controller. There MMU divides memory space to three sections: 000000 - ?FFFFF virtual ( mapped ) memory ?00000 - ?FFFFF physical memory ?00000 - FFFFFF IO space So in amy we could think something like: first 1 M Chip ram ----- 1 M next 8 M physical ram Some where ? M virtual ram high mem IO space We allocate portion of phys ram and disk for paging. MMU is initialized simply to provide normal address space + some virtual ram, normal address space is simply locked into memory. Page tables and paging area should probaply be protected against unauthorized modifications. Question is : Is there problems in this kind of layout? If virtual mem is addmem'd after boot, is there any reason why it woudn't work just like normal memory expansion? Pertti Lehtinen pl@tut.fi pl@tut.fi ! -------------------------------- ! Pertti Lehtinen ! Alone at the edge of the world ! Tampere University of Technology ! -------------------------------- ! Software Systems Laboratory
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/26/89)
Deven Corzine <deven@rpi.edu> writes in Message-ID: <DEVEN.89May24025106@daniel.rpi.edu> > Fine. But the RKM's say interrupt code and data MUST be in > MEMF_PUBLIC memory. Why? 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. > And yes, virtual memory will have far less damaging effects > than memory protection, with the design of the operating system -- the > message passing mechanism, in particular. I believe I already demonstrated why the contrary is true. 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
deven@rpi.edu (Deven Corzine) (05/26/89)
In article <8905260140.AA04445@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: Deven Corzine <deven@rpi.edu> writes in Message-ID: <DEVEN.89May24025106@daniel.rpi.edu> > Fine. But the RKM's say interrupt code and data MUST be in > MEMF_PUBLIC memory. Why? 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. > And yes, virtual memory will have far less damaging effects > than memory protection, with the design of the operating system -- the > message passing mechanism, in particular. I believe I already demonstrated why the contrary is true. 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. This is particularly evident in the message-passing mechanism, though it could obviously be patched so as to copy messages or perhaps to switch the protection of the message region to the recipient until the ReplyMsg... But if a program passes a pointer to its own buffer to another task, protected memory will break that sort of setup. Virtual memory, on the other hand, modifies the model mostly transparently. The only places where trouble arises is when something *must* be in physical memory. (interrupts, screen memory, etc.) The address space can be transparently expanded and manipulated without breaking as much. I stand by my statement. 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.
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/27/89)
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
deven@rpi.edu (Deven Corzine) (05/28/89)
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.
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/30/89)
Deven Corzine <deven@rpi.edu> writes in Message-ID: <DEVEN.89May28030529@daniel.rpi.edu> > "superior functionality"? What is inherently superior about a single > address space? Faster message passing, faster context switches (no need to copy memory and translate addresses (MOVES instruction)), but best of all, the ability of programs to access its other address space directly. I for one think its really neat to have hacks such as Vscreen, Dmouse, Snip-It and others which would be rather impossible to implement if the single addressing space was not used. > > I stand by the model of the ideal real-time message-based operating system. > > Exec is pretty good, but I wouldn't say ideal. I was saying that ideal is what I propose for virtual memory and memory protection. Indeed, Exec is not ideal as it stands now, but it will be after I upgrade it. :-) 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
deven@rpi.edu (Deven Corzine) (05/30/89)
In article <8905291930.AA10122@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > Faster message passing, faster context switches (no need to copy > memory and translate addresses (MOVES instruction)), but best of > all, the ability of programs to access its other address space > directly. I for one think its really neat to have hacks such as > Vscreen, Dmouse, Snip-It and others which would be rather impossible > to implement if the single addressing space was not used. Ah, but you see... it basically operates on the assumption that there is not only a single address space, but no memory protection as well... > I was saying that ideal is what I propose for virtual memory and > memory protection. Indeed, Exec is not ideal as it stands now, but > it will be after I upgrade it. :-) We'll see... 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.
doug@xdos.UUCP (Doug Merritt) (05/31/89)
In article <8905270516.AA18668@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >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 It's sad to see people get confused about such recent history. Your statement about RAM availability was true for microprocessors and some mini's but certainly not mainframes (or even all minis). And even there, address space limitations has certainly never been the only reason for giving tasks their own address space. One of the biggest reasons has always been for protection. It has generally been considered to be desirable, on say a timesharing system, to prevent any given process from clobbering some other poor person's program. >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. This is almost true. Unix *once* used that model. Berkeley Unix has had virtual memory since 1979. Prior to that, on PDP-11's, it absolutely *had* to swap (no paging support in hardware), so it wasn't a "poor memory model" at the time, on that hardware. It's true that AT&T fought tooth and nail to keep VM out of their versions of Unix, but even they gave up years ago, so both standard flavors of Unix have had VM for a long time. Longer than the Amiga has been out. BTW, the PDP 11 had 8 segment registers (8K each) defining each 64K address space, so shared memory on 8K boundaries could have been done. Wasn't in standard V6 or V7 Unix, though. In any case, having an MMU good enough to support swapping sure beats the crumby setup on Amiga's where you can't even do that! I really like Amiga's, but that's no reason to bad mouth swapping. Swapping is a pain *only* if you can outdo it, i.e. if you've got demand paged VM. >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. This is a really bizarre (as well as false) idea. A) Unix had 4Gig addressing on VAXen in 1979 B) Exclusively single address space OS's have traditionally been considered a major *defect* in OS design circles. C) It's true that for some things it's handy to allow shared address spaces, but only once you first have multiple address spaces. The fact that the Amiga guru's all the time demonstrates this quite easily -- crashes are *very* undesirable. Shared address space is great in real time systems, but ideally as an *option*, not as the only way to go! You young whippersnappers think you've got all the answers, but haven't even done your homework. For shame! >I stand by the model of the ideal real-time message-based operating system. Ok, sure, you're on solid ground there! >"An operating system without Name: Valentin Pepelea > virtual memory is an operating Phonet: (613) 231-7476 (New!) > system without virtue." Bitnet: 451061@Uottawa.bitnet I like your proverb. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
FelineGrace@cup.portal.com (Dana B Bourgeois) (05/31/89)
Valentin wants to add a requester that pops up when protected memory is
accessed in an unnacceptable way. The requester would tell you what
happened in the system with task xxx and task yyy and give you choices
on what to do about it. I *like* the idea because it gives me flex-
ibility with my old software on new hardware
** BUT **
what about Harold Super-Manager who isn't a whiz-bang computer nerd and
just wants to point and shoot. He gets the new A3500 with the latest
silicon and the fastest doohickeys and MEMORY-PROTECTION!! Suddenly all
his applications are popping up these requesters asking him to make
decisions about the innards of the OS. Doesn't sound like a good move
to make marketing-wise. How can you handle that problem? People who
don't want to know how it works, they just want it to work and keep on
working.
Dana
PS - there really are people out there using their A1000 all the time
and not once opening up a CLI. Just workbench and windowing utilities.
I think the protection requester would be a major scare.451061@UOTTAWA.BITNET (Valentin Pepelea) (06/01/89)
Doug Merritt <doug@xdos.uucp> writes in Message-ID: <360@xdos.UUCP> > In article <8905270516.AA18668@jade.berkeley.edu> 451061@UOTTAWA.BITNET > (Valentin Pepelea) writes: > > > 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 > > It's sad to see people get confused about such recent history. Your > statement about RAM availability was true for microprocessors and some > mini's but certainly not mainframes (or even all minis). Ridiculous! In the early 70's memory availablity was indeed a concern for mini computers, and in the early 60's it also was for mainframes. I was talking early history, dammit. > And even there, address space limitations has certainly never been > the only reason for giving tasks their own address space. > One of the biggest reasons has always been for protection. It has > generally been considered to be desirable, on say a timesharing system, > to prevent any given process from clobbering some other poor person's > program. Of course protection was a major reason for implementing memory management. But what I was discussing was the memory model, not the protection features. The shortage of ram favorises separate address spaces because it was simpler to just swap out an entire program and swap another one in, than to muck around like we do today. Those were the days of batch environments. Ick. > This is almost true. Unix *once* used that model. Berkeley Unix has > had virtual memory since 1979. Prior to that, on PDP-11's, it > absolutely *had* to swap (no paging support in hardware), so it wasn't > a "poor memory model" at the time, on that hardware. I was talking about early history, and here you come out and talk about 1979. 1979 is Yesterday mister! Anyway, you are just confirming that indeed history is the reason why Unix uses the inefficient superflous memory model. > It's true that AT&T fought tooth and nail to keep VM out of their > versions of Unix, but even they gave up years ago, so both standard > flavors of Unix have had VM for a long time. Longer than the Amiga has > been out. Another confirmation. Not only is Unix brain damaged due to history, but its designers were heavely sedated too! > ... but that's no reason to bad mouth swapping. Swapping is a pain > *only* if you can outdo it, i.e. if you've got demand paged VM. I was not bad-mouthing page swapping. I was bad-mounting the suggestion that we implement separate address spaces, like brain-damaged Unix does. Oh brother! > A) Unix had 4Gig addressing on VAXen in 1979 I was talking about early history, not 1979. The damage was done by the. > B) Exclusively single address space OS's have traditionally been > considered a major *defect* in OS design circles. Again, you are mixing up time-zones. Today, there is only one advantage to having separate address spaces: the ability to layer operating systems on top of each other. That's what virtual machines are all about. Not exactly what an Amiga user whishes to do with his computer. > C) It's true that for some things it's handy to allow shared address > spaces, but only once you first have multiple address spaces. > The fact that the Amiga guru's all the time demonstrates this > quite easily -- crashes are *very* undesirable. Whoa! You are mixing up the "memory model" with "memory protection". The Amiga Gurus very much not because a single address space is shared, but rather because no protection is implemented. That will get fixed very soon. > Shared address space is great in real time systems, but ideally as an > *option*, not the only way to go. Whoa! You are really mixed up! Shared memory is a *requirement* in real-time systems. It is an option is those 'other' brain-damaged systems. Throw that wisky bottle away! > You young whippersnappers think you've got all the answers, but haven't > even done your homework. For shame! Anybody can take my words and twist them around as they please. I am not surprised to see that from a Unix junkie like you. :-) > I like your proverb. > Doug It will be outdated by the end of the summer. Perhaps sooner. 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
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/01/89)
Dana B Bourgeois <FelineGrace@cup.portal.com> writes in Message-ID: <18977@cup.portal.com> > Valentin wants to add a requester that pops up when protected memory is > accessed in an unnacceptable way. The requester would tell you what > happened in the system with task xxx and task yyy and give you choices > on what to do about it. I *like* the idea because it gives me flexi- > bility with my old software on new hardware > > ** BUT ** > > what about Harold Super-Manager who isn't a whiz-bang computer nerd and > just wants to point and shoot. He gets the new A3500 with the latest > silicon and the fastest doohickeys and MEMORY-PROTECTION!! Suddenly all > his applications are popping up these requesters asking him to make > decisions about the innards of the OS. Doesn't sound like a good move > to make marketing-wise. How can you handle that problem? People who > don't want to know how it works, they just want it to work and keep on > working. 1. By the time the A3500 comes out, devellopers better get their act straight. 2. Meanwhile the manager can call the develloper's support line to ask what option he should choose on the requester. 3. In case of doubt, choose "Guru". 4. In case of doubt, choose "Allow all future accesses" (for adventurous types) The requester will be confusing at first, but just like users have learned to type "dir", "copy" and "delete", they will now learn one more trick. 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
doug@xdos.UUCP (Doug Merritt) (06/01/89)
On the subject of single address space OS's, Valentin and I have a few disagreements, and I notice that my previous article was rather scathing in tone. Sorry about that, no offense intended. In article <8906010252.AA11810@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >> > 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 I disagreed, and Valentin said in the early 60's ram was limited even on mainframes. True, but the point is that limited ram is *not* why separate address space support was designed into MMU's and OS's. It was because this was considered to be a feature. Each program thought it owned the whole machine. Again, this is desirable for *most* programs, even on the Amiga, due to the way most programmers write code. Some programs behave very well and take the whole environment into account, but far more do not. >Of course protection was a major reason for implementing memory management. >But what I was discussing was the memory model, not the protection features. >The shortage of ram favorises separate address spaces because it was simpler >to just swap out an entire program and swap another one in, than to muck around There is no particular advantage to having a single address space if protection keeps you from writing outside of it, e.g. to system structures, so the distinction between the protection model and the memory model that you keep making is pointless. It's true that PDP 11 Unix swapping into a tiny address space was desirable because the address space *was* tiny. But note that swapping is still done when necessary on demand paged systems because *physical* ram is always a limited resource. 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! Conversely, physical ram is always limited, and so virtual memory *is* desirable to be able to do some things at *all*. Where I work we have an application that requires up to 60 megabytes of RAM. The poor feeble Sun 3/280 server can only support 24Meg of physical RAM. Without virtual memory, we'd be out of business. So if given the opportunity (e.g. a 68020 and an MMU), virtual memory is an absolute requirement. That leaves us with either choosing swapping or private address spaces. 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. 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. 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. We can't (cleanly/simply/fully) introduce such a model to a new rev of the Amiga hw/sw because the system is committed to use of shared memory for message passing and for modification of system structures. Thus, despite the advantages of the Amiga approach, it also has some severe inherent design problems that lead to the machine crashing when some task goes bad. No matter how someone justifies it, this is not desirable, and it is an excellent reason for other systems using private address spaces by default. There are very effective real time systems that do this, and that allow tasks to share address spaces *by special request*, and under controlled circumstances that will not crash the machine. Even the tasks that need inherently dangerous access to hardware resources can be managed by limiting such access to "trusted" tasks, rather than allowing all programs such access, whether they need it or not. Because of this it just doesn't make sense to claim that a single address space model is inherently superior to multiaddress space models. It depends on what kind of application program you're thinking of. Each is good for some reasons and bad for others (basically performance versus safety). >> It's true that AT&T fought tooth and nail to keep VM out of their >> versions of Unix, but even they gave up years ago, [...] > >Another confirmation. Not only is Unix brain damaged due to history, but its >designers were heavely sedated too! Huh? You're not making your thinking clear. Yes, AT&T is brain damaged. Yes, System III Unix was brain damaged. But since System V.4 and Sun OS 4.0 and BSD 4.3 all support both demand paged virtual memory *and* shared memory, what's your beef? >I was not bad-mouthing page swapping. I was bad-mounting the suggestion that we >implement separate address spaces, like brain-damaged Unix does. Oh brother! Calling Unix "brain damaged", or bad mouthing any technical feature, does not sufficiently explain your point(s). Most of what you *seem* to be arguing doesn't make sense so far to those of us who have had to deal with the technical tradeoffs in question. It sounds like you're theorizing without complete facts, thus the strong disagreement. Perhaps I'm just misunderstanding your position. >Again, you are mixing up time-zones. Today, there is only one advantage to >having separate address spaces: the ability to layer operating systems on top >of each other. That's an example of what I mean. There demonstrably *are* other advantages, thus this statement is confusing. >That's what virtual machines are all about. Not exactly what an >Amiga user whishes to do with his computer. I disagree, at least in part, but that's another issue. (Ok, briefly: what about those who have said they'd like to have both AmigaDOS and Minix running at the same time!?) >> Shared address space is great in real time systems, but ideally as an >> *option*, not the only way to go. > >Whoa! You are really mixed up! Shared memory is a *requirement* in real-time >systems. It is an option is those 'other' brain-damaged systems. Throw that No, it is a requirement *for some tasks*, not for *all* tasks to share a single address space. As I said before, you get the maximum advantage of virtual memory management if most tasks are in private memory, and if it is an option to allow any two given tasks to share (some part of their) address spaces. The phrasing is confusing, I suppose, since I meant that it is a requirement to have the option! >Anybody can take my words and twist them around as they please. I am not >surprised to see that from a Unix junkie like you. :-) Thanks for the smiley face, but I really don't think I'm twisting your words. I think that I strongly disagree with your argument regardless of the phrasing of it. As for being a Unix junkie, I've been using Unix and C for a long time, but all I can say is that they are the best portable environments currently available. I've been dying for *more* powerful environments for a decade. I see some things that are improvements in some ways (e.g. AmigaDOS has some features that are nicer than those in Unix), but as far as across the board features are concerned, I'm still waiting. >> I like your proverb. >> Doug > >It will be outdated by the end of the summer. Perhaps sooner. I'll look forward to that. Sad that it won't prevent guru's, though. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
usenet@cps3xx.UUCP (Usenet file owner) (06/02/89)
In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >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 Nope. It must *think* that it is at the same place in memory. MMUs can make an actuall block of memory at hardware address $cef3d appear to the CPU as if it were acutally at $d3fec. Better yet, with an MMU and some clever software, memory address $cef3d can actaully be stored at block #543212 on your disk. (Note: the actuall numbers given here are not important) This problem is no different than the one-address-space-per-process model. THink of it this way: The 680x0 can address 2^32 bytes. With a UNIX type memory managament system, that works out to be 2^32*#of process (given enough disk space :-) ). On a single address space VM system, you would be strictly limited to 2^32 bytes - for everything. Since most people cannot afford to buy 2^32 bytes worth of semiconductors for their computer, VM was invented. When a the CPU makes a reference to a particular address, the MMU does a table look up, to discover where the information at that address is currently stored. It could be that the byte at that address is actually in memory, but it will probably be at a different actuall address. In this way, the MMU is just a function, like y=f(x). The CPU plugs in 'x' and expects to get what it thinks ought to be at that location. If the info is not in memory, the MMU picks a chuck of memory to swap out. It gets written to disk, the needed block is loaded in is place, and the address mapping function is updated. Simple huh? > >address spaces, or even on systems with a single address space but >each task limited to writing in the memory that belongs to it. > >We can't (cleanly/simply/fully) introduce such a model to a new rev of >the Amiga hw/sw because the system is committed to use of shared memory >for message passing and for modification of system structures. Yes we can. Any program can read any address. The MMU makes sure the right thing gets back to the CPU. The MMU should also *enforce* protected areas, so that even though Program A can peek at Program B, it wont be allow to poke it. > >Because of this it just doesn't make sense to claim that a single address >space model is inherently superior to multiaddress space models. It Bah! > This is an example of a short .signature jap@frith.cl.msu.edu
jesup@cbmvax.UUCP (Randell Jesup) (06/02/89)
In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >There is no particular advantage to having a single address space if protection >keeps you from writing outside of it, e.g. to system structures, so the >distinction between the protection model and the memory model that you >keep making is pointless. Single address space and protection are seperate issues. Another thing to realize is that protection doesn't necessarily mean protection from another process reading your memory. With one address space, you can read lists and structures owned by different processes, which makes message passing with pointers work much better. >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. Wrong. The whole point of VM is that the addresses can be mapped. A single address space merely means that all processes share a single mapping of virtual->physical. Your hypothetical situation only arises if processes can have different mappings. >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. Protection (if implemented - various historical things make this tough) would solve most of this, with a single address space. >We can't (cleanly/simply/fully) introduce such a model to a new rev of >the Amiga hw/sw because the system is committed to use of shared memory >for message passing and for modification of system structures. > >Thus, despite the advantages of the Amiga approach, it also has some >severe inherent design problems that lead to the machine crashing when >some task goes bad. We cannot ever make it impossible, but we can cut way down on the probability of it for MMU-based machines. There's nothing we can do for 68000-based machines (which is almost all our installed base, though the number of '020/'851 and '030 machines is definitely increasing. In fact, protection is by far most useful for developers. >No matter how someone justifies it, this is not desirable, and it is an >excellent reason for other systems using private address spaces by >default. There are very effective real time systems that do this, and >that allow tasks to share address spaces *by special request*, and under >controlled circumstances that will not crash the machine. Even the tasks >that need inherently dangerous access to hardware resources can be >managed by limiting such access to "trusted" tasks, rather than allowing >all programs such access, whether they need it or not. However, this is not an option on 68000 machines, and even on MMU based machines it can greatly increase the overhead. This has nothing to do with single-address-space, though. >I disagree, at least in part, but that's another issue. (Ok, briefly: >what about those who have said they'd like to have both AmigaDOS and >Minix running at the same time!?) Virtual machines are an amusing idea, and can be useful for debugging OS's (slowly) on fairly generic machines, but the killer is hardware access. You can only safely give I/O hardware access to the main OS, and any virual machines running become very problematical when they start trying to twiddle hardware registers and get results. You either have to have simulators for every piece of hardware, or trap the low-level OS I/O routines for the virtual machine and pass them to the main OS. You could write a minix kernel that ran UNDER exec/intuition/etc, and BESIDE AmigaDos (see Devin's an my long exchange for more info). >No, it is a requirement *for some tasks*, not for *all* tasks to share >a single address space. As I said before, you get the maximum advantage >of virtual memory management if most tasks are in private memory, and >if it is an option to allow any two given tasks to share (some part of >their) address spaces. The phrasing is confusing, I suppose, since I >meant that it is a requirement to have the option! VM and single address space and protection are ALL seperate issues. The only thing they have in common is that they involve the MMU. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
eachus@mbunix.mitre.org (Robert Eachus) (06/02/89)
In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >In article <8906010252.AA11810@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >>> > 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 > >I disagreed, and Valentin said in the early 60's ram was limited even on >mainframes. True, but the point is that limited ram is *not* why separate >address space support was designed into MMU's and OS's. It was because >this was considered to be a feature. Each program thought it owned the >whole machine. Again, this is desirable for *most* programs, even on >the Amiga, due to the way most programmers write code. Some programs >behave very well and take the whole environment into account, but far more >do not. I was there Charlie! And the reason most 70's computers gave each user his own address space was that they had run out of address bits, and putting each user in his own box, postponed the architectural doom date for a few more years. The clearest example is the PDP-11 which started life with 16-bit hardware and instruction-set adresses. As this limit became more and more intolerable, the hardware addresses were upped (to a final figure I think of 22-bits), but addresses in programs were still required to be 16-bits max. Having separate data and instruction address spaces was added to give programmers one more effective address bit, but boy did it make things messy. Writing programs which do page table swapping is even messier, but many of the early sixties architectures were even more brain-dead than the PDP-11. The PDP-1 had 12-bit address (to 18-bit words), and four pages. The PDP-8 had 128-word pages (of 12-bit words), and the in the IBM-360 most addresses were 10-bit offsets from 32-bit registers (but the addresses were calculated modulo 2**24 -- 16 Meg). Fortunately, all machines which require page table swapping in user progams have been obsolete for years and have all probably been scrapped by now...or in the case of IBM-PC's and clones, should have been. :-) Of course, some people, forced by necessity or brain death to use such obsolete architectures, claim that in memory paging is an advantage. But I would never, even with a gun to my head, buy a machine which supported more physical memory than was directly addressable in normal address modes. If all users can share a portion of their address space with the operating system, many operations become vastly easier. When the Amiga makes full use of the virtual memory capabilities of the 2620 boards or the 68030, I expect that it will still maintain a model where all addresses are unique, so that messages paseed between processes can contain pointers, etc... At least until the Amiga 9000 is released, with support for 16 Gigabytes or more of RAM. (Or maybe it will change in the Amiga 8000, with only 4 Gig, because of virtual memory. :-) Gordon Bell said it all: (this may not be exact) "No computer architecture has ever become obsolete for any reason other than a lack of address bits." He should know, he designed the PDP-15 nee PDP-1 instruction set archecture (with other incarnations as the PDP-4, PDP-7, and PDP-9), the PDP-8 nee PDP-5 ISA, the DECsystem-20 nee PDP-6 ISA (a.k.a PDP-10, and Decsystem-10) and the PDP-11 ISA all of which bit the dust for just that reason. (There are still some DEC-20's around. By then the address space had been increased to 256K of 36-bit words. But the others are all dead, dead, dead.) The Amiga architecture may outlive the VAX, because it has one or two more effective address bits available. (The VAX uses the top two bits of 32-bit addresses as mode bits, but I expect that when they hit the limit that will change.) Recently the need for address bits has been increasing at a rate of almost one a year. If we say that with 1.3 Amigas require 1-Meg, then most of the current Amigas will run out of physical address space in about 3 or 4 years, but it will take another 10 years to hit the architectural limit of the 680x0 family. Note that reserving 4 Meg of address space for CHIP RAM was a foresighted decision. But a new address map will be needed in say 1992, but that one would be needed to support more than 16 Meg on the FAST bus anyway. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
doug@xdos.UUCP (Doug Merritt) (06/02/89)
In article <3244@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >>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 > >Nope. It must *think* that it is at the same place in memory. MMUs can >make an actuall block of memory at hardware address $cef3d appear to the Right. But that doesn't make a difference, because once you do this, you have gone and created separate address spaces already! The fact that all of your tasks might *all* be loaded at the same virtual address (and different physical addresses) means that you've already given up the single address space model that I was arguing against. The tasks may have *some* shared address space, but it is no longer the simple "single address space". To reiterate, you can't use the single address space model because it would force loading (reloading/swapping) of tasks into a fixed physical address, screwing up virtual memory management. The apparent fix of making it a fixed *virtual* address instead means that you've given up the idea of the pure single address space model. QED. > [ ...description deleted...] >If the info is not in memory, the MMU picks a chuck of memory to swap >out. It gets written to disk, the needed block is loaded in is place, >and the address mapping function is updated. Simple huh? Overall, that was a nice description of how VM could work. And yes, it's pretty simple. >>We can't (cleanly/simply/fully) introduce such a model to a new rev of >>the Amiga hw/sw because the system is committed to use of shared memory >>for message passing and for modification of system structures. >Yes we can. Any program can read any address. The MMU makes sure >the right thing gets back to the CPU. The MMU should also *enforce* >protected areas, so that even though Program A can peek at Program B, it >wont be allow to poke it. Yes, you could do that. No, it won't be sufficient. It will prevent message passing between cooperating tasks, because the memory needs to be in shared read/write memory. If you write-protect AmigaDOS data pages as well as user task pages, then you prevent things like installing your own volume nodes, and in general you break all those custom hacks like vscreen, backdrop, dropshadow, etc. >>Because of this it just doesn't make sense to claim that a single address >>space model is inherently superior to multiaddress space models. It > >Bah! Monosyllabic pejoratives like this really detract from technical discussions. Look, I may say stupid things, I may not see your point, maybe we can figure out a way around the problems, but it's illogical not to at least seriously consider what I say, simply because I have experience with the subject. I've designed MMU hardware architecture for real systems, I've implemented custom OS's, hacked Unix, and coped with existing VM OS's (Unix and otherwise) as a user. This doesn't prevent my making mistakes, but it does mean that I'm not totally ignorant of the subject. To assume that the person on the net you're arguing with is an idiot who should be dismissed with terms like "Bah!" is to limit your own information gathering resources. Sometimes a disagreement can be the source of important new knowledge. Next time it might not be *me* you dismiss, it might be somebody *really* smart! :-) :-) Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/03/89)
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
usenet@cps3xx.UUCP (Usenet file owner) (06/03/89)
In article <369@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >In article <3244@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >>In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: > >The fact that all of your tasks might *all* be loaded at the same virtual >address (and different physical addresses) means that you've already No, you load each program at a unique virtual address space. This would work the same as it does now, each task gets loaded into a particular address, that cant change until it exits and gets reloaded. Hmmm... I think we are not quite talking about the same thing somehow. The way I picture it, VM with a single address space, and no protection of any sort, would give the appearance to any programs running in it that there is a lot more memory than there really is. Instead of upgrading your A2500 from 2megs to 8, just install VM. >To reiterate, you can't use the single address space model because it >would force loading (reloading/swapping) of tasks into a fixed physical >address, screwing up virtual memory management. The apparent fix of >making it a fixed *virtual* address instead means that you've given >up the idea of the pure single address space model. QED. I do not understand why a program at virtual address X would always need to be at a fixed real address Y. The only thing that needs to stay the same is the virtual address. To change the real address, say when a block needs to be reloaded, just update the MMU tables. After the system has been up for a while, each physical block of memory is mapped into some virtual address, and there would be no appearent (definitly not linear) correspondence between virtual and physical addresses, but the MMU makes it look like it by translating the addresses coming out of the CPU. Note: this would be a problem for memory-mapped IO, since actuall addresses are important then. The MMU would need to be informed enough not to remap the IO space to someplace else. > [ much stuff deleted ] >>Bah! > >Monosyllabic pejoratives like this really detract from technical >discussions. Look, I may say stupid things, I may not see your point, Sorry, no offence intended. I have never worked with the insides of a VM system at all. I have not even looked at documentation for an MMU like the '551, but I thought that I had a good understanding of the works. Perhaps I'm mistaken. This is an example of a short .signature jap@frith.cl.msu.edu
jms@doctor.Tymnet.COM (Joe Smith) (06/03/89)
Would you believe that an airline reservation system runs on a single-address
system without memory protection? It's surprising they don't have more
problems. Aren't you glad we don't have 1800 hard disks on a single Amiga?
Newsgroups: comp.risks
Subject: RISKS DIGEST 8.74
Message-ID: <12497182468.17.NEUMANN@KL.SRI.COM>
Date: 26 May 89 23:13:37 GMT
From: Andrew Birner <Andrew-Birner%ZENITH.CP6%LADC@BCO-MULTICS.HBI.HONEYWELL.COM>
Subject: SABRE disaster caused by "core corruption"
According to an article by Margie Semilof, entitled "SABRE Recovers from
Network Crash", in Communications Week, May 22, 1989, the recent SABRE outage
occurred when the "Online DASD formatter was changed erroneously by another
software program operating at the same time. This 'core corruption' resulted
in the destruction of critical system data on SABRE's 1,800 DASDs."
The article later quotes Jim Juracek, vice president of systems engineering
for SABRE Computer Services:
"All the predictable things are covered," Juracek said. "The unpredict-
able things, such as when a software program gets clobbered by another
program . . . [ellipsis hers] there is no way to work with this."
------------------------------
Newsgroups: comp.risks
Subject: RISKS DIGEST 8.76
Message-ID: <12498530828.14.NEUMANN@KL.SRI.COM>
RISKS-LIST: RISKS-FORUM Digest Wednesday 31 May 1989 Volume 8 : Issue 76
From: WHMurray@DOCKMASTER.NCSC.MIL
Subject: SABRE
>Is SABRE is too tightly coupled to its hardware to be moved to a
>platform that provides hardware memory protection? Or is it just plain
>too big to be ported?
SABRE, like most reservation systems, runs on ACP or TPF. These
high-performance, limited function operating systems run on hardware with
memory protection, i.e., 370 XA. However, for performance reasons, they do
not exploit the isolation features of the hardware. All application code
runs in a single address space and at the same level of privilege.
While this strategy is inherently dangerous, there are compensating controls
imposed on application code. The strategy has been very successful. The
res systems have achieved extraordinary reliability and stability for any
kind of system, let alone systems which are both mammoth and monolithic.
[discussion of portability deleted]
If you were to begin today, knowing what we know, you would never permit
anything so large and monolithic to come into existence. On the other hand it
is too large, important, valuable, and vital to kill. Like many other
successful applications from the sixties, it has a life of its own. While we
may migrate many of its functions to compartmented sub-systems, the core is
likely to be with us for a very long time.
William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
--
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"deven@rpi.edu (Deven Corzine) (06/03/89)
In article <7039@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > You could write a minix kernel that ran UNDER >exec/intuition/etc, and BESIDE AmigaDos (see Devin's an my long >exchange for more info). ["Deven". ;-)] I'm working on it. (but not Minix itself.) > VM and single address space and protection are ALL seperate >issues. The only thing they have in common is that they involve the >MMU. And memory, of course. :-) 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.
doug@xdos.UUCP (Doug Merritt) (06/04/89)
In article <8906030123.AA14671@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >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. Yes, I was at various times talking about various different things, and worse yet I was speaking about VM design in *general* rather than what is most desirable on the Amiga; you're quite right that that clouded the issue. I finally realized this in my posting just *after* the one you replied to most recently, and changed the Subject: line to reflect that an entire proposal was contained therein. Since I think I took pretty much everything into account in that one, in a much clearer way, I'm going to defer comment on the current batch of VM postings until I see some response to that one. I'm saving these other postings in case a response is still called for at that point. >Doug's operating system: >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. I can see how you thought so, but truly none of these five points apply to what I suggest in the actual proposal; you'll see. Sorry to have been so unclear previously! Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
FelineGrace@cup.portal.com (Dana B Bourgeois) (06/07/89)
Valentin, it appears you don't understand the kind of people I am talking about. I work in an engineering office where the computing is handled by clerks on I*M XT machines with dBase III, Lotus123, and two flavors of word processor. These clerks were taught the programs by the programmers (who cut their teeth on Microsoft Basic and then moved on to dBase III) and they have learned enough about the programs to update them for output of reports. These people do not know DOS, and they definitely do not understand the working of the machines. Maintanence of ANY sort is handled by a corproate contract just like with the Xerox machines. Now by model 3500 I would hope that Amigas would also be found in business settings just like the I*M and M*c machines are now. And as with these two machines, many (most?) of the users will not know the machine beyond the applications and the workbench. People like this you don't want making decisions like whether to GURU or to disable memory protection or any of the other stuff in your proposed solution. For you and me and even someone like (ugh!!) Jerry Pournelle, the requestor would allow a realistic, rational, concious decision. But the people I see accessing computers, using computers, and even programming computers would be scared by such a requestor, confused by such a requestor, and wouldn't be able to understand the choices being offered. And these are the people who will justify the purchase of millions of Amiga 3500 so they must be factored into the decision. Sure they can just learn by trial and error. But too many GURUs will earn the Amiga the reputation of unreliability. Management buys I*M cause it is safe. They buy M*c cause it is easy to use or because it prints good. Speed has little to do with it and cost virtually nothing. My boss is asking for two computers right now, a M*c and a PS-2. With printers and software and installation and stuff the total cost is about $15K. If he doesn't get it it'll be because his boss doesn't want us to have a computer, not for any other reason. A bad reputation will PRECLUDE the Amiga from consideration in business. Apple saw it clearly, the appearance of friendliness, ease of use, and good graphics(especially in hard-copy) are worth the drawbacks of cost, hi-cost I mean, relatively slow speed, and difficulty in programming because the money is made when the end-users buy the machine. The moral is: Never under-estimate the illogical stupidity of end-users. Dana
daveh@cbmvax.UUCP (Dave Haynie) (06/08/89)
in article <8906030123.AA14671@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) says: >> 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. 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. About the only obvious advantage of the private-space-per-task model is that it makes memory allocation tracking much easier to do, since you need only allocate memory contiguously, and thus keep track of only the start and finish of your allocated memory, vs. the list that a single-space OS will need for each task. But memory tracking is simple, anyway (it could even be added to AmigaOS on a per-task basis easily), it's the tracking of other resources that both systems have to deal with properly, and that's got nothing to do with the memory space model. > Valentin -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ske@pkmab.se (Kristoffer Eriksson) (06/09/89)
In article <8906030123.AA14671@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Valentin's AmigaOS 2.0: > >1. Single addressing space. >2. Virtual memory. >3. Memory protection. ----------------- >4. Resource tracking. >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. :-) How can the OS and MMU provide any protection, if they don't care what program is using what memory? -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
fnf@estinc.UUCP (Fred Fish) (06/12/89)
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
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/12/89)
Kristoffer Eriksson <ske@pkmab.se> writes in message <1251@pkmab.se> > How can the OS and MMU provide any protection, if they don't care what > program is using what memory? Hire me, and I'll tell you. Actually, tell Commodore to hire me, and then everybody can use my "Virtual Memroy, Memory Protection" handler. Heh. No Kidding. 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
doug@xdos.UUCP (Doug Merritt) (06/13/89)
In article <8906120031.AA03511@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Kristoffer Eriksson <ske@pkmab.se> writes in message <1251@pkmab.se> > >> How can the OS and MMU provide any protection, if they don't care what >> program is using what memory? > >Hire me, and I'll tell you. Actually, tell Commodore to hire me, and then >everybody can use my "Virtual Memroy, Memory Protection" handler. Heh. No What, you're not going to answer questions until you get hired? How strange. Actually it would be more to the point to explain your brilliant ideas in sufficient detail that somebody eventually says "Hey, this guy's pretty sharp, we should hire him." Sounds sort of like you ran out of enthusiasm for the subject when you reply like that. "I know better than you but I can't be troubled to explain." Most companies are more likely to get fired up about hiring a patient explainer. See also "team player". Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
ske@pkmab.se (Kristoffer Eriksson) (06/14/89)
In article <8906120031.AA03511@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Kristoffer Eriksson <ske@pkmab.se> writes in message <1251@pkmab.se> > >> How can the OS and MMU provide any protection, if they don't care what >> program is using what memory? > >Hire me, and I'll tell you. Actually, tell Commodore to hire me, and then >everybody can use my "Virtual Memroy, Memory Protection" handler. Heh. No >Kidding. The way I know protection, it means that when one program is executing, it has access to some memory, and no access to the rest of the memory, and when another program executes, that program does not have access to the same parts of memory, at least not all of it. Thus something in the MMU setup must change when execution transfers from one program to another. But if nothing in the system cares about such things, I don't understand how it is going to work. In a system with a monolithic kernel (like UNIX), I could imagine a simple way to protect the kernel from the user programs without protecting the user programs from each other, but the Amiga has a lot of separate tasks in stead of a single kernel, so that does not apply. And it would only be half a protected system as I see it, anyway. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/16/89)
Kristoffer Eriksson <ske@pkmab.se> writes in message <1251@pkmab.se> > > How can the OS and MMU provide any protection, if they don't care what > program is using what memory? Imagine the Unix OS where each program has its own addressing space. Every program then has its virtual pages mapped either onto disk, or onto some scattered chunks of physical memory. Each program therefore has its own translation table which maps a virtual addressing range starting at 0. On a single addressing space OS, you have the exact same thing, except that rather than having the virtual addresses start at 0, they start at arbitrary and exclusive locations. This is not the ideal implementation, but it is the best one the 68851 can offer. If I were allowed to design my own MMU, I would use a single translation table, where each page descriptor entry would also contain an "owner" field. This owner field would then be compared to the current task ID, and thus the access priviledge would be determined. Easy thing to design, but since the 68030 & 68040 have 68851-like MMUs already built in, this would be a waisted effort. 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
daveh@cbmvax.UUCP (Dave Haynie) (06/19/89)
in article <1265@pkmab.se>, ske@pkmab.se (Kristoffer Eriksson) says: > In a system with a monolithic kernel (like UNIX), I could imagine a simple > way to protect the kernel from the user programs without protecting the user > programs from each other, but the Amiga has a lot of separate tasks in stead > of a single kernel, so that does not apply. And it would only be half a > protected system as I see it, anyway. If you give each task under Exec it's own MMU map (same basic idea as UNIX), it would be fully possibly to protect every task from every other one. Of course, once you start using messages, you have to allocate some memory that's shared between tasks, and that leaves it open for a mutant task to bugger up someone else's messages. Though you might expect that, until a task asks for shared memory or the use of the messaging system, it's not given access to any shared memory. It wouldn't perhaps be as bullet proof as UNIX, but it would be fairly tough. Both UNIX and AmigaOS count on an OS function to do the task switching -- it's not like one task passes off to another without help from the OS (things like math chips wouldn't work correctly if this were happening). > -- > Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden > Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se > Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
peter@sugar.hackercorp.com (Peter da Silva) (06/20/89)
In article <8906160430.AA09545@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > This is not the ideal implementation, but it is the best one the 68851 can > offer. What does the 68451 have to do with the AmigaDOS memory layout? The MMU wasn't even considered when the OS was written. You're blaming the hardware for the sins of the software. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/21/89)
Peter da Silva <peter@sugar.hackercorp.com> writes in Message-ID: <3936@sugar.hackercorp.com> > In article <8906160430.AA09545@jade.berkeley.edu>, 451061@UOTTAWA.BITNET > (Valentin Pepelea) writes: > > This is not the ideal implementation, but it is the best one the 68851 can > > offer. > > What does the 68451 have to do with the AmigaDOS memory layout? The MMU > wasn't even considered when the OS was written. > > You're blaming the hardware for the sins of the software. > -- > Peter "Have you hugged your wolf today" da Silva `-_-' > ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` Your message is totally out of context. Get enlightened, fellow. Valentin _________________________________________________________________________ The godess of democracy? "The Name: Valentin Pepelea tyrants may distroy a statue, Phonet: (613) 231-7476 but they cannot kill a god." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Confucius Planet: 451061@acadvm1.UOttawa.CA
jesup@cbmvax.UUCP (Randell Jesup) (06/27/89)
In article <96@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes: >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. Well, maybe, but usually that's the result of a lurking bug that was there all along. The most famous of these is the infamous "null pointer dereference" common among programmers used to working on BSD Vaxen. We're working on improving your ability to make programs crash for these reasons, via a suite of stuff that can make the system VERY unforgiving. Sort of like a super-memmung - stuffs freed memory with garbage odd values, corrupts location 0, moves stuff around, checks for low-memory trashing, has some double-checks (like the Bryce's new io_torture) on system calls to catch common mistakes, like reusing an in-use message, etc. Not perfect at catching them, and definitely slows down the system, but good for developers doing testing. We may also use the MMU to catch other mistakes, like accessing non-existant (or maybe even free) ram (ala setcpu TRAP). Phew, only 270 more messages to read in .tech! :-( That's what I get for going to devcon, then being afraid to even look at news for a week after- wards! Thanks to all who voted for me in Marco's survey/whatever, it's nice to know your help is appreciated. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup