edwin@hcr.UUCP (Edwin Hoogerbeets) (08/29/88)
In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>: [somebody besides Matt writes] >>: An idea central to the Amiga >>:is that an address in any tasks address space is not a virtual >>:address but a physical memory address. That means that you can hand >>:a pointer off to another task and it will be valid in THAT tasks's address >>:space. >> Yes, this *IS* a nice idea. >Personally I think this is the single biggest problem with the Amiga. I agree with Fred. The idea of a process is that the situation should look, to the process itself, as if it is the king of the CPU. No-one else is on this machine. If communication should occur, then you should assume the process you are talking to is on another machine (when it really is on the same one, but hey, let's be sneaky and not tell the first process about it!) This is the theoretical "higher concept". One example of the disadvantage of this "pointer passing in msgs" is that it makes things difficult to do networking at the OS level. Making message passing transparent on a network is difficult because you don't know if a pointer to some memory is being passed. (Same as the problem with fork() on the 68000/no mmu about not knowing which data are pointers) However, I can see how no mmu/memory protection/etc. can appeal to hackers. "Do what I say, and I'll be happy." Matt and others have produced some very nice software because of it. Also, passing messages and data structures by pointer is FAST. Also, queues are a lot shorter because you are only passing 32 bit quantities. I just wonder what's going to happen on the 2500 and 3000... Edwin (Deepthot) Hoogerbeets uunet!utai!utcsri!hcr!edwin
rminnich@super.ORG (Ronald G Minnich) (08/30/88)
In article <3859@hcr.UUCP> edwin@hcrvax.UUCP (Edwin Hoogerbeets) writes: >I agree with Fred. The idea of a process is that the situation should >look, to the process itself, as if it is the king of the CPU. No-one >else is on this machine. If communication should occur, then you should I could not disagree more. The reason is simple. There is an easy way to do networking at the OS level within the framework of the shared-memory model. You make the network look like a large shared memory. No less an authority than Vint Cerf (one of the creators of tcp/ip) has said this is a good future direction for networking. A prototype of such a network has been built at udel, called MemNet. I have been working on how to use such a beast for around two years now. Hint: the obvious ways don't work well. On the other hand, it sure makes networking easier. The goal is sharing of data. The way the amiga shares data leads to a very high-performance, low-cost box. using my A500 windows is a real relief after using a Sun 3-280 with X11 and their variable latency and poor mouse response. Finally, i realized this morning that i screwed up the description of how Sprite works. Try again: For all processes on a given sprite multiprocessor, address (e.g.) 0 will refer to the same piece of data. Now that may move around as pages are mapped etc, and not all processes may have access to that page (e.g. there is protection), but given that a process has access to an address it will be pointing to the same piece of data as other processes that have access to that same address. Have i obfuscated enough yet? Sigh. For some reason i have a hard time describing this, yet it is so simple and clean. Currently this hold for Unix kernel space, i.e. all the unix kernel space addresses are the same for all processes. All sprite does is extend that to kernel and user spaces. It makes sharing much nicer and eliminates lots of problems. ron P.S. I think the days of 'king of the CPU' are numbered, if not gone. People *like* building solutions that involve multiple workers. It is so much easier.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/31/88)
:However, I can see how no mmu/memory protection/etc. can appeal to :hackers. "Do what I say, and I'll be happy." Matt and others have :produced some very nice software because of it. Also, passing messages :and data structures by pointer is FAST. Also, queues are a lot shorter :because you are only passing 32 bit quantities. : :I just wonder what's going to happen on the 2500 and 3000... : :Edwin (Deepthot) Hoogerbeets :uunet!utai!utcsri!hcr!edwin Yes, an interesting theoretical problem. But actually, not so bad. Currently, allowing a (single) application which runs (multiple) processes to have the processes run on different machines is completely up to the designer of the software. And it will be like this for the rest of eternity, because no matter how you look at it, passing pointers around will ALWAYS be faster than passing buffers.... even if the buffer passing is implemented by mapping the same page to N processes. Usually, even if the OS *does* allow the processes to run on different machines, the overhead involved in such a scheme where the processes don't KNOW they are on different machines can be tremendous... so much so that it isn't worth it for the most part. So, at least for the next 50 years, there will be a distinction. Now, for machines with VM there are essentially two memory models used today that I know about. (1) Global address space (2) Independant address space. In (1) All processes on the machine share the same address space (4 gig usually), and thus all addresses are unique even between processes. In (2) All processes have their own address space with (possibly) limited sharing ... all addresses are NOT unique between processes. NOTE THAT BOTH METHODS USE THE MMU HEAVILY TO IMPLEMENT PROTECTION AND OTHER STUFF, SUCH AS PAGING, SWAPPING, ZERO-ON-REFERENCE, ETC... For the amiga, method (1) Is the only possibility due to the dependance on pointer passing (BTW, I consider this *GOOD* because it makes the entire OS streamlined). I happen to like (1) for a couple of reasons. -Shared memory, when allowed, is inherent rather than a special case. -Entire data structures, especially structures that contain pointers, may be shared. -Pointer passing and sharing can be accomplished without having to translate addresses or 'trick' the process with MMU manipulations. -Shared libraries become inherent and extremely easy to implement -You don't need to clear the A/D cache when you switch between processes! NOTE: Note, I use the word 'machine'... physically independant machines which do not share memory (i.e. all the processors in a parallel processing machine are considered as a single entity). -Matt
jesup@cbmvax.UUCP (Randell Jesup) (08/31/88)
In article <3859@hcr.UUCP> edwin@hcrvax.UUCP (Edwin Hoogerbeets) writes: >In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >>In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>>: [somebody besides Matt writes] >>>: An idea central to the Amiga >>>:is that an address in any tasks address space is not a virtual >>>:address but a physical memory address. That means that you can hand >>>:a pointer off to another task and it will be valid in THAT tasks's address >>>:space. >>> Yes, this *IS* a nice idea. >>Personally I think this is the single biggest problem with the Amiga. Well, in some ways it's one of it's biggest wins, as well. It makes for VERY fast (but simple) IPC, which the OS relys on heavily. Removing that from the OS would make it grind to a (comparitive) halt. This was the reason for MEMF_PUBLIC. Unfortunately, what should be public is not clearly defined, and many of the RKM examples do things like have static msgports (instead of allocating them with memf_public). Also, memf_public is a bit weak as a metaphor, and the lack of consistency of use would cause great problems in enforcing it. You could _almost_ ignore public with several tricks, except for one thing: private msgports. They would be in the tasks address space, and the OS has no way of knowing that they should be writable by another task. Public msgports aren't a problem, since they are registered with the OS. This would require lots of mods to things like putmsg, and all device drivers would have to run in supervisor mode. Programs that pass ptrs to other application processes would have to be reved, or run in some compatiblity mode. The alternative is to make most memory (or all) readable to all processes. For this, there would have to be one flat address space for all processes (not a really bad idea, it saves LOTS of virtual->physical mapping calls, and makes the OS much less monolithic than the Unix kernal. Overall, this hypothetical OS would be more resistant to crashes, though not 100%. Drivers and handlers would have to be trusted. Libraries would have to be rewritten, and would be slower for anything that had to reference information in the library base (or elsewhere). And obviously, you'd have to run it on an '020 with MMU (or design a custom mmu for the 68000, but then performance would likely be lousy.) >I agree with Fred. The idea of a process is that the situation should >look, to the process itself, as if it is the king of the CPU. No-one >else is on this machine. If communication should occur, then you should >assume the process you are talking to is on another machine (when it >really is on the same one, but hey, let's be sneaky and not tell the >first process about it!) This is the theoretical "higher concept". For this level of communication, see peter et al's IPC stuff. >However, I can see how no mmu/memory protection/etc. can appeal to >hackers. "Do what I say, and I'll be happy." Matt and others have >produced some very nice software because of it. Also, passing messages >and data structures by pointer is FAST. Also, queues are a lot shorter >because you are only passing 32 bit quantities. The FAST bit is the important bit. memory allocation is slow, and so is copying, especially when you're dealing with bitmaps... :-( -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/01/88)
Actually, the address CAN be a virtual address if you use a linear address space for all tasks. That is, if task A has some pointer variable X which it passes to task B, task B can reference that pointer without translating the (pointer) value of X... B might need PERMISSION to do so via its page table, but the keyword is 'NO translation required'. This does not mean that X must point to physical memory, just as long as the MMU MAP is to a unique address, see? Thus, you can give processes access to each other's memory on a per-process basis, and even though this is restricted to the page size of the MMU, it is still better than no protection at all. Specifically, a task would be able to say "This is protected and nobody but me can access it". For example, if you allocate stacks in multiples of the page size, you can put one or more unmapped pages at both ends of your stack space and thus trap any stack overruns or underruns that occur.... hell, you could put a 32K dead space on either end if you wanted because with an MMU one has the entire address space to put things in. Then we get to keep our IPC message-pointer passing model and go FAST PLUS HAVE MEMORY PROTECTION all at the same time. Gee Wiz (sarcastic smiley). -Matt :: [somebody besides Matt writes] :: An idea central to the Amiga ::is that an address in any tasks address space is not a virtual ::address but a physical memory address. That means that you can hand ::a pointer off to another task and it will be valid in THAT tasks's address ::space. : Yes, this *IS* a nice idea. :>>Personally I think this is the single biggest problem with the Amiga. : : Well, in some ways it's one of it's biggest wins, as well. It makes :for VERY fast (but simple) IPC, which the OS relys on heavily. Removing that :from the OS would make it grind to a (comparitive) halt. : : Overall, this hypothetical OS would be more resistant to crashes, :though not 100%. Drivers and handlers would have to be trusted. Libraries : : The FAST bit is the important bit. memory allocation is slow, :and so is copying, especially when you're dealing with bitmaps... :-( -Matt
ain@s.cc.purdue.edu (Patrick White) (09/01/88)
In article <8808311759.AA19249@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > This does not mean that X must point to physical memory, just as long >as the MMU MAP is to a unique address, see? > Thus, you can give processes access to each other's memory on a >per-process basis, and even though this is restricted to the page size of >the MMU, it is still better than no protection at all. Specifically, a >task would be able to say "This is protected and nobody but me can access it". Why not just have a separate virtual address space for each process's shared memory, and have the pointers contain which task's virtual address sapce it is for.. for those familiar with the 8086 architecture, I'm talking about something similar to a separate segment for each task (I looked at the way the 8086 was done once, and decided that segements are a good idea, just not the way intel implemented them). Of course, this won't work for the current 68000 architecture as it would ideally be supported at the ucode level. For the current implementation, we could always make everyone use the MEMF_PUBLIC flag and too bad for the people who were sloppy. :-).. it's really the same kind of thing as happened with fast memory -- sloppy programs broke. -- Pat White ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906 [let's all help Joe out... send your IFF pictures or music to joe@dayton.UUCP]
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/01/88)
:In article <8808311759.AA19249@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
:> This does not mean that X must point to physical memory, just as long
:>as the MMU MAP is to a unique address, see?
:> Thus, you can give processes access to each other's memory on a
:>per-process basis, and even though this is restricted to the page size of
:>the MMU, it is still better than no protection at all. Specifically, a
:>task would be able to say "This is protected and nobody but me can access it".
:
: Why not just have a separate virtual address space for each process's shared
:memory, and have the pointers contain which task's virtual address sapce it is
You mean under a 'standard' VM model where each process has the same
address space (everybody starts at 0 model) and part of that is reserved for
shared memory? Two reasons:
(1) It introduces special cases (the set-aside address space is a
special case)
(2) For the Amiga at least, it is not a feasible solution with all
the message passing processes do... that is, it is not something
that can be added without rewriting just about the entire OS.
: Of course, this won't work for the current 68000 architecture as it would
:ideally be supported at the ucode level.
I figure a standard MMU will do the job, no? Not saying I like the
method, just wondering if I missed something? The VAX is the only machine I
know whos microcode knows about the MMU extensively.
: For the current implementation, we could always make everyone use the
:MEMF_PUBLIC flag and too bad for the people who were sloppy. :-).. it's really
:the same kind of thing as happened with fast memory -- sloppy programs broke.
No way. MEMF_PUBLIC was never defined well and subsequently not used
consistantly (probably not even by the OS). EVERYTHING will break!
-Mattewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/01/88)
In article <673@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes: >P.S. I think the days of 'king of the CPU' are numbered, if not gone. >People *like* building solutions that involve multiple workers. >It is so much easier. I can see it now: The year 2108. The new Amiga 4.29e32 is released. It has one CEO processor; ten processors to carry out the CEO's directions, kept on a seperate PCB (board of directors); several dozen processors to manage internal operations; and about a hundred processors to do the actual work, controlled by a number of supervisory processors. Communication between the processors is a strict tree, with the CEO at the root. Processors distribute data to all processors beneath them; no processor may communicate to another processor at its own level without going passing the data through the processor above it for approval. Any attempt to communicate without going through the proper channels results in the offending processor being taken off-line. The system is reasonably efficient, but you can't really do anything creative with it. Also, the worker processors have this annoying tendency to cease working until the owner agrees to allow them to work less and consume more current. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
fnf@fishpond.UUCP (Fred Fish) (09/01/88)
In article <8808311759.AA19249@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Then we get to keep our IPC message-pointer passing model and go FAST >PLUS HAVE MEMORY PROTECTION all at the same time. In my original comment on this subject it might appear that I was against the "all addresses are physical addresses" concept, which I certainly am not. What I want, and absolutely require in any future machine I buy for serious purposes (I.E. use to generate income to put a roof over my head and food on the table), is: Support for interprocess memory protection that is hardware based (cannot be subverted by runaway processes as some software implementations can). I can allow or disallow access to any range of addresses that I desire, modulo certain alignment and size restrictions. Thus I can have totally private code or data space and shared code or data space for which any combination of read, write, or execute permissions can be granted. Thus I can keep others from mucking around in my data structures, and build "pits" into which other processes can dump whatever data they want, that I can use cautiously after looking it over carefully. Other than this, I only mentioned virtual memory because the hardware used to provide memory protection is commonly powerful enough to also permit virtual memory. The virtual memory could be done at a level "below" that of every process, so that it simply appeared to most of the kernel and to all processes that you had an unlimited amount of physical memory. -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113