dix@clinet.FI (Risto Kaivola) (08/01/90)
I have read comp.sys.amiga.xxxx groups and seen plenty of information about the new Amiga operating system version 2.0. I've probably missed something, because I don't know does the OS2.0 use the MMU to prevent those nasty Gurus. Therefore, I have the following questions: 1)If the OS2.0 does not support the MMU upto the extent where all application programs could run independently, i.e not corrupting other programs' data, can you tell me what is the reason? 2)If the OS2.0 supports the MMU (I'd really like it to happen) will this cause any compatibility problems with the older versions of the OS? 3)If the OS2.0 doesn't support the MMU, is it because the UNIX version for the amiga (in the distant future) will? 4)Are there some hardware related things that could prevent me using the MMU while bypassing the OS? 5)Are there any existing programs using the MMU? If you think this topic is not found generally interesting by comp.sys.amiga.tech readers, free feel to email. Risto -- Risto Kaivola Jakalatie 2 B 10 Internet: dix@clinet.fi 00730 Helsinki UUCP: ...mcsun!santra!clinet!dix FINLAND VOICE: + 358 0 367 249
pl@etana.tut.fi (Lehtinen Pertti) (08/01/90)
From article <2489@clinet.FI>, by dix@clinet.FI (Risto Kaivola): > > I have read comp.sys.amiga.xxxx groups and seen plenty of > information about the new Amiga operating system version 2.0. I've > probably missed something, because I don't know does the OS2.0 use the > MMU to prevent those nasty Gurus. Therefore, I have the following > questions: > > 1)If the OS2.0 does not support the MMU upto the extent where all > application programs could run independently, i.e not corrupting other > programs' data, can you tell me what is the reason? > AmigaDOS message passing mechanism is based on pointer passing, which means that communicating processes must have shared dataspace. And I afraid that there exists programs, which don't allocate their messages with MEMF_PUBLIC flag on, but instead use their stack or even code segment. And that means that even these can't be protected. > > 2)If the OS2.0 supports the MMU (I'd really like it to happen) will this > cause any compatibility problems with the older versions of the OS? > I afraid so. > > 3)If the OS2.0 doesn't support the MMU, is it because the UNIX version > for the amiga (in the distant future) will? > These are totally unrelated things, actions of some future UNIX don't affect OS2.0 in any way. > > 4)Are there some hardware related things that could prevent me using the > MMU while bypassing the OS? > If you are bypassing OS, nothing could prevent anything from you. OS uses MMU to protect itself from bypassing. -- pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
ckp@grebyn.com (Checkpoint Technologies) (08/02/90)
In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: >1)If the OS2.0 does not support the MMU upto the extent where all >application programs could run independently, i.e not corrupting other >programs' data, can you tell me what is the reason? > No, OS 2.0 does not use the MMU to protect applications from tromping on each other's, or the systems, memory. This is because there are so many applications that share memory structures, and in the past these applications have not been bound to inform the OS of their intentions. When you don't tell the OS in advance what memory you're going to share, then the OS cannot make any distinction between normal, healthy sharing, and an unhealthy, amok program trouncing other applications. Yes, there's been a lot of traffic in the comp.sys.amiga.xxx groups about this. Unfortunately, I haven't heard a workable solution for existing applications, I can't think of one myself, and many net.folk whose opinions I respect have claimed it can't be practically done. Therefore, the way to get MMU protection for your applications is to abandon application binary compatibility; and if you're going to do this anyway, then why not just use Unix? -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
gow@sakari.mrceg (Ed Gow) (08/02/90)
Is there movement toward correcting message allocation for MMU use is the long term?? -- ------ Ed Gow ------ uwm!mrsvr!gemed!sakari!gow ----------- My opinions are NOT those of GE. Three cheers and a tiger for me!
zahra@wolfen.cc.uow.oz (Andrew Zahra Telecom) (08/02/90)
In article <20889@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: > > Yes, there's been a lot of traffic in the comp.sys.amiga.xxx groups > about this. Unfortunately, I haven't heard a workable solution for > existing applications, I can't think of one myself, and many net.folk > whose opinions I respect have claimed it can't be practically done. > > Therefore, the way to get MMU protection for your applications is to > abandon application binary compatibility; and if you're going to do > this anyway, then why not just use Unix? > -- Wouldn't it be possible to phase in mmu support by having a mechanism to let the os know if your program can handle having an mmu protect things from it.This way the things would progressively become more stable as more of these new prgs appear - old prgs would just have their protection mask set to have access to all memory and they'd never know the difference...
ckp@grebyn.com (Checkpoint Technologies) (08/02/90)
In article <6405@wolfen.cc.uow.oz> zahra@wolfen.cc.uow.oz (Andrew Zahra Telecom) writes: >In article <20889@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: >> >> Yes, there's been a lot of traffic in the comp.sys.amiga.xxx groups >> about this. Unfortunately, I haven't heard a workable solution for >> existing applications, I can't think of one myself, and many net.folk >> whose opinions I respect have claimed it can't be practically done. >> >> Therefore, the way to get MMU protection for your applications is to >> abandon application binary compatibility; and if you're going to do >> this anyway, then why not just use Unix? >> -- > > Wouldn't it be possible to phase in mmu support by having a mechanism to >let the os know if your program can handle having an mmu protect things from it.This way the things would progressively become more stable as more of these new >prgs appear - old prgs would just have their protection mask set to have access >to all memory and they'd never know the difference... I think this is grand. In fact, Commodore seems to be planning this, because they already have plans to implement Virtual Memory. Unfortunately VM does not necessarily imply "protection". It offers only a larger virtual memory area than available physical memory provides. My definition of "Protection": Where each program has a unique virtual address space, and where the address space of all other programs is unaddressable, except in such case that two tasks formally agree to share some memory space and make this known to the OS. When any program addresses memory which is not in it's virtual address space, it bombs. But also note: even though other programs have been protected by this trap, the OS itself has not been unless it has knowledge of all the resources owned by the program, and can reclaim them. Therefore "Protection" implies "resource tracking". -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/04/90)
In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: > > 1)If the OS2.0 does not support the MMU upto the extent where all > application programs could run independently, i.e not corrupting other > programs' data, can you tell me what is the reason? Backward compatibility. > 2)If the OS2.0 supports the MMU (I'd really like it to happen) will this > cause any compatibility problems with the older versions of the OS? The new version of the operating system does rather little with the MMU. The intial Amiga 3000's use the MMU to load a disk-based image of kickstart into fast ram and translate it at $F80000, thus allowing their shipment without the need to burn in ROMs. If the kickstart is in ROM, the c:cpu command can also copy the ROM image into RAM for speed improvement, and the c:cpu 'trap' option invalidates page zero and addresses above 2 gig, and prints out reports on the serial port at 9600 baud. The number of bugs that we have found with such trap handlers is incredible. > 3)If the OS2.0 doesn't support the MMU, is it because the UNIX version > for the amiga (in the distant future) will? That's like stating that GM will not produce Buicks anymore because they are already shipping Pontiacs. Unix has nothing to do with the future plans for the useage of the MMU. Unix is like a fully loaded '76 Cadillac Eldorado, with power steering, power brakes, power windows, power door locks, power andjustable seats, automatic transmission and anti-burglar alarm. It is large gas-guzlling boat which will get you where you want, comfortably, but you better put a V-8 in it, or else you will notice the lack of power despite a reasonable engine. When driving over a speed bump you will not notice anything. AmigaDOS is like a Mazerati Biturbo. It is low-slung sexy foreign sports car with a convertible top. And the MMU trap-handlers and other debugging tools that can be found are like a mechanic in the passenger seat. You are better off with one of those in Italian cars. When driving over a speed bump, you can see sparks flying off the bottom of the car, and the passenger gets thrown out if the convertible top is off. > 4)Are there some hardware related things that could prevent me using the > MMU while bypassing the OS? Nope. > 5)Are there any existing programs using the MMU? SetCPU, the utility written by Dave Haynie, the c:cpu command which provides similar functionality, a few trap-handlers that detect accesses to invalid memory locations, and the A3000 release of WB 2.0. Ah yes, and the virtual memory handler develloped by a bright young university student as a 4th year project. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/04/90)
In article <20927@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > > I think this is grand. In fact, Commodore seems to be planning this, > because they already have plans to implement Virtual Memory. > Unfortunately VM does not necessarily imply "protection". It offers only > a larger virtual memory area than available physical memory provides. > > My definition of "Protection": Where each program has a unique > virtual address space, and where the address space of all other programs > is unaddressable, except in such case that two tasks formally agree to > share some memory space and make this known to the OS. Actually, memory protection and separate adress spaces are two different concepts, just like virtual memory is distinct from memory protection. If memory protection is implemented on the Amiga, then all tasks will have to share the common 4 Gig adress space. All tasks would be allowed to read each other's memory, but would be allowed to write only to specifically permitted memory. Due to the popularity of Unix, we are tempted to understand operating system concepts in terms of how Unix has been implemented. It is very difficult to convince a programmer that a global addressing space is much more efficient and versatile than a separate addressing spaces as implemented in Unix. The history of hardware capabilities have limited the memory model of Unix to what we are familiar with now, and that is likely to limit the intellectual capabilites of programmers for years to come. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (08/04/90)
G'day, In article <20889@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: RK> In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: RK> 1) If the OS2.0 does not support the MMU upto the extent where all RK> application programs could run independently, i.e not corrupting other RK> programs' data, can you tell me what is the reason? RK> [Sorry to remove the context of your reply but bandwidth etc.] [Essentially apps. don't tell the OS how they're sharing memory/messages] It is your following point that has me thinking/followup-ing. CKP> Therefore, the way to get MMU protection for your applications is to CKP> abandon application binary compatibility; and if you're going to do CKP> this anyway, then why not just use Unix? In what sense do you mean "binary compatibility" and abondonment of it? Could the OS set up a way for memory protection that application writers could elect to use such that it could be possible to run _only_ memory protective programs? {Sorry about the run on sentence}. This might smack of the Macintosh cooperative approach to multitasking but it is at least interesting to ask whether it could work in theory at least. Is the OS itself "un-memory protectable"? {Boy I'm having a bad day grammar wise. :-)} Boy I hope you guys don't string me up for that question {heresy? :-)}. yours truly, Lou Cavallo.
peter@sugar.hackercorp.com (Peter da Silva) (08/05/90)
In article <20889@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > Therefore, the way to get MMU protection for your applications is to > abandon application binary compatibility; and if you're going to do > this anyway, then why not just use Unix? Real-time response? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jeh@athena.sisd.kodak.com (Ed Hanway) (08/06/90)
valentin@cbmvax (Valentin Pepelea) writes: >In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: >> >> 1)If the OS2.0 does not support the MMU upto the extent where all >> application programs could run independently, i.e not corrupting other >> programs' data, can you tell me what is the reason? > >Backward compatibility. As an intermediate step to full memory protection, why not just forbid read and write access to free memory? This won't do a thing to stop programs from corrupting each other, but it might help catch the bugs that cause these problems. I think the only "correct" programs that might break under this scheme would be those that use the kind of non-standard memory allocation like VD0:. -- Ed Hanway (speaking for myself, not my employer)
hclausen@adspdk.CBMNET (Henrik Clausen) (08/06/90)
>In article <1990Aug6.115552.14352@sisd.kodak.com> jeh@athena.sisd.kodak.com (Ed Hanway) writes: >valentin@cbmvax (Valentin Pepelea) writes: >>In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: >>> >>> 1)If the OS2.0 does not support the MMU upto the extent where all >>> application programs could run independently, i.e not corrupting other >>> programs' data, can you tell me what is the reason? >> >>Backward compatibility. > >As an intermediate step to full memory protection, why not just forbid read >and write access to free memory? This won't do a thing to stop programs >from corrupting each other, but it might help catch the bugs that cause >these problems. I believe the MMU is designed to handle fairly large chunks of memory at at time, so on a system with badly fragmented memory, this might not work very well? I've been considering that the system could provide us with some new memory allocation calls, so that applications can ask for memory that is protected _and_ virtual (and tracked?), though non-interchangeable with other tasks. As the typical use of large amounts of memory is for uses within one task rather than for intertask communications, this could provide an easy way for DTP, Gfx, and other memory intensive programs to have unlimited, protected memory in an easy way, and could hardly break anyone. Correct me if I'm letting my mind go wild. Have a nice day -Henrik -- | Henrik Clausen, Graffiti Data (Fido: 2:230/22.33) | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Do not accept the heart that is the slave to reason" - Qawwali trad__/
ckp@grebyn.com (Checkpoint Technologies) (08/06/90)
In article <13625@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <20927@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >> >> My definition of "Protection": Where each program has a unique >> virtual address space, and where the address space of all other programs >> is unaddressable, except in such case that two tasks formally agree to >> share some memory space and make this known to the OS. > >Actually, memory protection and separate adress spaces are two different >concepts, just like virtual memory is distinct from memory protection. >If memory protection is implemented on the Amiga, then all tasks will have to >share the common 4 Gig adress space. All tasks would be allowed to read each >other's memory, but would be allowed to write only to specifically permitted >memory. Having worked with IBM mainframes of pre-MMU vintage, I know this is possible. And, after thinking about it, this is probably most appropriate for a machine with the Amiga's heritage, where all tasks already share the same virtual address space. >Due to the popularity of Unix, we are tempted to understand operating system >concepts in terms of how Unix has been implemented. It is very difficult to >convince a programmer that a global addressing space is much more efficient >and versatile than a separate addressing spaces as implemented in Unix. The >history of hardware capabilities have limited the memory model of Unix to >what we are familiar with now, and that is likely to limit the intellectual >capabilites of programmers for years to come. Well, now, give me some credit here! :-) I just happen to like separate virtual address spaces better, for various reasons (which are all rather trivial); I'm not just stuck on a Unix mentality. As it happens, Unix exposure came late in my professional life, limited to the last two years. Before that it was VMS, before that it was PDP-11 (bare, no OS), and before that I dealt with IBM mainframes. A single, fully shared virtual address space (like our current fully shared physical address space) allows rapid message passing by indirect pointer, rather than by copying messages from one address space to another. A region of shared memory between the communicators is all that's needed, however, and this can be done as well by declaring such a region in a system with separate virtual address spaces. Unless the messages sent contain even more indirect pointers, and then it gets stickier, and you might as well declare the two tasks' spaces equivalent. Separate independent virtual address spaces are more secure (more of an issue in a multi-user OS), allow non-PIC code without a relocating loader (and if the code section is pure then the original segment on disk may be used as the backing store of the code segments rather than using the page file), allows for a total system virtual memory capacity of (number of tasks) * 2**32, rather than "only" 2**32. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
ckp@grebyn.com (Checkpoint Technologies) (08/06/90)
In article <893@ucsvc.ucs.unimelb.edu.au> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: >G'day, >In article <20889@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: > >CKP> Therefore, the way to get MMU protection for your applications is to >CKP> abandon application binary compatibility; and if you're going to do >CKP> this anyway, then why not just use Unix? > >In what sense do you mean "binary compatibility" and abondonment of it? Well, specifically I meant the ability to protect today's program binaries. I may not have said that well; I surely see an OS which can run both protected and unprotected (old) binaries. Of course, you're only really protected if you only run protected binaries... >Could the OS set up a way for memory protection that application writers could >elect to use such that it could be possible to run _only_ memory protective >programs? {Sorry about the run on sentence}. I'm sure. But what this gives is protection for new applications designed to be protected. It doesn't give protection to old applications, and it doesn't protect our new applications from an old application running concurrently. Just be aware of that, and there's no problem. >Is the OS itself "un-memory protectable"? {Boy I'm having a bad day grammar >wise. :-)} Since it is the OS that we must rely upon to enforce protection, then by definition it must be "trusted" and not "protected". -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
ckp@grebyn.com (Checkpoint Technologies) (08/06/90)
In article <20889@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > Therefore, the way to get MMU protection for your applications is to > abandon application binary compatibility; and if you're going to do > this anyway, then why not just use Unix? In article <6303@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Real-time response? Valid point. You could choose another appropriate real-time protected kernel. I hear Mach is nice; I wish I knew more about it. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
markv@kuhub.cc.ukans.edu (08/06/90)
I've had several thoughts on this subject and here are mine... There is a big difference between virtual memory and process protection. In a lot of ways, virtual memory is easier since much fewer things will have problems with it. Well, heres some thoughts on some topics. MEMF_PUBLIC: This has to be the most misused and abused flag on the Amiga system. Many programs use it to say give me CHIP or FAST, even though 0L does that. Many programs dont use it at all. Many programs (as mentioned before) do things like use static structures, auto variables, etc. for public things. I think the best thing is to give a some new flags so programmers can start using them and then provide a manager to turn on and off default behavior (preferably for individual programs) to catch bugs and make existing things work. Have a combination of things like PUBLIC/PRIVATE/SYSTEM where public is ANY task, system in OS tasks only, and private is forced private (to override defaults). Also have flags for READ/WRITE/READWRITE etc. System calls: Remember that many calls that deal with shared messages like Do/Send/BeginIO(), Get/PutMsg(), etc, execute in the callers context, so they can be patched to set up privleges/access correctly in a protected environment. The message structure itself can be patched for R/W access by the system. Based on the system calls, it can be known whether buffers are read only or read/write, etc. Address Space: I strongly belive that a shared address space is best for the Amiga. Just about EVERYTHING on the Amiga is some form of pointer linked structures. Using independant memory spaces makes this difficult to nearly impossible. Unix programmers know this problem having to deal with things like forcing data structures into arrays, etc. Implementation: Set the standards NOW. Provide the hooks to support it NOW. Provide the tools to control it to users NOW. Enforce the behavior LATER. This way developers can began to fix software to support it using known standards, developers and advanced users can try it, find problem software, and make existing software work with temporary fixes. Most programs will require only small changes make things work. Update compilers to provide support for the new features. Add keywords like private, public, etc to suppplement chip. Lots of the previous suggestions make sense. Patch LoadSeg() to fix up hunks in memory. Make code Read only, data can be set to default to read only or read write, or private to catch problems. Giving system routines full read/write access will solve most problems for now. Leave current behavior as the default, so users will continue to have the machine work the same way. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jesup@cbmvax.commodore.com (Randell Jesup) (08/07/90)
In article <1990Aug6.115552.14352@sisd.kodak.com> jeh@athena.sisd.kodak.com (Ed Hanway) writes: >valentin@cbmvax (Valentin Pepelea) writes: >>Backward compatibility. > >As an intermediate step to full memory protection, why not just forbid read >and write access to free memory? This won't do a thing to stop programs >from corrupting each other, but it might help catch the bugs that cause >these problems. I think the only "correct" programs that might break >under this scheme would be those that use the kind of non-standard memory >allocation like VD0:. However, the granularity has to be increased to 256 bytes (smallest page size in the MMU), and you need _big_ page tables, and the overhead of AllocMem/FreeMem gets much larger. Probably not something I'd want for a production user environment for the moment. Other things break: anything that frees part of an allocation. This is at best only quasi-legal, though layers currently does it with cliprects to reduce overhead/fragging. Good debugging tool, though. Fix the programs and all users benefit. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
peter@sugar.hackercorp.com (Peter da Silva) (08/08/90)
In article <13625@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: > Due to the popularity of Unix, we are tempted to understand operating system > concepts in terms of how Unix has been implemented. It is very difficult to > convince a programmer that a global addressing space is much more efficient > and versatile than a separate addressing spaces as implemented in Unix. To a certain point, this is true. Eventually, though, you run out of address bits. In the 16 bit world this has led to Split I/D segments and then segment registers. In the 32-bit world it's just starting to happen. Time for a 64 bit address space? (see comp.arch for more info) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/08/90)
In article <1990Aug6.115552.14352@sisd.kodak.com> jeh@athena.sisd.kodak.com (Ed Hanway) writes: > > As an intermediate step to full memory protection, why not just forbid read > and write access to free memory? This won't do a thing to stop programs > from corrupting each other, but it might help catch the bugs that cause > these problems. As I said in my previous message, this has just been done. And indeed a very large amount of software is caught in the act thanks to this utility. Often people on the net feel that their suggestions go unnoticed. I hope the Guardian-Angel proves that to be false. Keep them coming. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/08/90)
In article <20999@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > >>The history of hardware capabilities have limited the memory model of Unix to >>what we are familiar with now, and that is likely to limit the intellectual >>capabilites of programmers for years to come. > >Well, now, give me some credit here! :-) I just happen to like separate >virtual address spaces better, for various reasons (which are all rather >trivial); I'm not just stuck on a Unix mentality. My message was discussing the mentality of the average programmer, not yours personally. You have proven yourself through previous messages to quite different. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/09/90)
In article <25174.26bd4fa9@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: > > MEMF_PUBLIC: > > This has to be the most misused and abused flag on the Amiga system. Ignored, yes. Misused, maybe. Abused, no. It is impossible to abose this flag, even if a fool might was to allocate CHIP or FAST by using it. > System calls: > > Remember that many calls that deal with shared messages like > Do/Send/BeginIO(), Get/PutMsg(), etc, execute in the callers context, > so they can be patched to set up privleges/access correctly in a > protected environment. The message structure itself can be patched > for R/W access by the system. Based on the system calls, it can be > known whether buffers are read only or read/write, etc. Unfortunately not. The is a field in the message structure which specifies the length of the message. Unfortunately, nobody ever sets that field to its proper value. Therefore when a Task A sends a message to Task B, the operating system has no way to know what length of memory should have its protection changed. > Implementation: > > Set the standards NOW. Provide the hooks to support it NOW. Provide > the tools to control it to users NOW. Enforce the behavior LATER. Well, we could come up with a tool that checks for the proper useage of the MEMF_PUBLIC flag when necessary. As to the proper useage of the mn_Length field of message structures, it too can be checked for, but so many applications never set it, that it would be disastrous to enforce it in the future. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/09/90)
In article <6315@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >> It is very difficult to convince a programmer that a global addressing space >> is much more efficient and versatile than a separate addressing spaces as >> implemented in Unix. > > To a certain point, this is true. Eventually, though, you run out of address > bits. In the 16 bit world this has led to Split I/D segments and then segment > registers. In the 32-bit world it's just starting to happen. Time for a 64 > bit address space? > > (see comp.arch for more info) Bad example. The comp.arch example involves a data file that contains so much information, it is overflowing the the 4,300 Meg limit of IBM's VSAM. Virtual storage and virtual memory are two different concepts. And in the IBM world, where a file is not a stream of characters, and where an ASCII character just isn't, we cannot even compare the two. Now it's my turn to give a really bad example. "This planet is too small for the two of us. Proof? I can hop into a space shuttle and blast away from earth." Indeed the 4 Gig address space offered by the 680x0 family could be overflowed if a programmer really wanted to. But then I could write a program right now which would overflow the address space of a 64-bit computer. Whether a programmer chooses to be smart and not need so much memory, whether he chooses to develop under an operating system that offers separate address spaces, or whether he chooses to divide his program into overlays is irrelevant. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
gilgalad@zip.eecs.umich.edu (Ralph Seguin) (08/09/90)
In article <1990Aug6.115552.14352@sisd.kodak.com> jeh@athena.sisd.kodak.com (Ed Hanway) writes: >valentin@cbmvax (Valentin Pepelea) writes: >>In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes: >>> >>> 1)If the OS2.0 does not support the MMU upto the extent where all >>> application programs could run independently, i.e not corrupting other >>> programs' data, can you tell me what is the reason? >> >>Backward compatibility. > >As an intermediate step to full memory protection, why not just forbid read >and write access to free memory? This won't do a thing to stop programs >from corrupting each other, but it might help catch the bugs that cause >these problems. I think the only "correct" programs that might break >under this scheme would be those that use the kind of non-standard memory >allocation like VD0:. >-- >Ed Hanway >(speaking for myself, not my employer) Why not make code segments read only as well? This would kill off all ugly self-modifying code. Personally, I th8ink that Commodore should define their paradigm and present it to developers so that they can be prepared for it. In any case, I'm sure the people at Commodore are well aware of what is needed. See ya, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
gilgalad@zip.eecs.umich.edu (Ralph Seguin) (08/09/90)
In article <6315@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <13625@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >> Due to the popularity of Unix, we are tempted to understand operating system >> concepts in terms of how Unix has been implemented. It is very difficult to >> convince a programmer that a global addressing space is much more efficient >> and versatile than a separate addressing spaces as implemented in Unix. > >To a certain point, this is true. Eventually, though, you run out of address >bits. In the 16 bit world this has led to Split I/D segments and then segment >registers. In the 32-bit world it's just starting to happen. Time for a 64 >bit address space? > >(see comp.arch for more info) >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. The IBM POWER series has a 56 bit (I think that's the right number) address space. That's quite a bit of space 8-) See ya, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
peter@sugar.hackercorp.com (Peter da Silva) (08/10/90)
In article <21001@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > In article <20889@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > > Therefore, the way to get MMU protection for your applications is to > > abandon application binary compatibility; and if you're going to do > > this anyway, then why not just use Unix? > In article <6303@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Real-time response? > Valid point. You could choose another appropriate real-time protected > kernel. I hear Mach is nice; I wish I knew more about it. CMU will send you pretty full docs if you ask them. I don't recall the address, try postmaster@cmu.edu. One point, though, is that Mach is not yet real-time. Virtual memory and realtime have never been particularly comfortable in bed together... and VM is basic to the Mach design. One intriguing possibility is running virtual Amigas under Mach. I suspect that you could write a custom pager for it that would give pretty close to real-time response. You'd have to make AmigaOS do a suspend operation instead of halting (I *assume* AmigaOS halts when there is no work to do). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
david@twg.com (David S. Herron) (08/10/90)
In article <13624@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Unix is like a fully loaded '76 Cadillac Eldorado, with power steering, power >brakes, power windows, power door locks, power andjustable seats, automatic >transmission and anti-burglar alarm. It is large gas-guzlling boat which will >get you where you want, comfortably, but you better put a V-8 in it, or else >you will notice the lack of power despite a reasonable engine. When driving >over a speed bump you will not notice anything. Well.. mebbe compared to Amiga DOS ... Unix looks rather Lean and Mean compared to some systems like VMS (for instance). For instance, Unix *still* doesn't require 5 feet of manuals. (Err.. well, there is the Sun OS manuals, and the Ultrix manuals.. both of which are about that much manuals). But then, I work at writing X/Motif programs in an OSI development group. For some reason *everything* looks small.. ;-) -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/11/90)
In article <6322@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >of halting (I *assume* AmigaOS halts when there is no work to do). Yes, it does. A nice STOP instruction. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."