ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/10/90)
There was a discussion a while back about the virtues of protected operating systems. A number of people seem to believe that PCs in general, and Macintosh in particular, will become much more reliable once they start to enforce a separation between user-level and kernel-level code. Frankly, I'm a little skeptical. As a regular user of both a Mac and a VAX/VMS cluster, I'd have to say that the relative frequency of crashes of the two systems, leaving aside the times I crash either one while debugging my own software, is something in the region of 10:1. That is, it's not as much as 100:1. Now, if it were 100:1, you could claim that a protected system is truly wonderful, and would effect a great improvement in the reliability of the system. But 10:1 is probably comparable to the ratio of crashes that you would get between different Mac users running different applications, or using the same applications in different ways. You could effect a comparable amount of improvement by tightening up the quality control on your software development. In other words, I don't think protected mode is worth it. Even if you disagree with my numbers (feel free to come up ones with some real evidence behind them, by all means), there are more fundamental problems. Consider a couple of Mac applications that I have installed on my machine right now: After Dark and Adobe Type Manager. In a protected system, would they be ordinary user-mode code, or would they need to run in privileged mode? If they can run in user mode without any special privileges, then any other user-level code could use the same hooks, run amuck, and render my screen display totally unusable. The kernel may still be running undamaged, but as far as I'm concerned, my system has crashed. On the other hand, if these two applications would need to run privileged, then I would argue that a significant number of other applications out there would also have reason to run privileged. What good is a protection system with lots of exceptions to it? Our VAXcluster runs several applications requiring some level of privilege. For example, the TCP/IP product that we use, called Multinet, loads itself into system memory as an extension to the VMS kernel (analogous to TSRs under DOS, or INITs on the Mac). A couple of months ago it hung; the rest of VMS kept running, but all TCP/IP services became unusable. The only way to clear the problem was to restart the system, which would have annoyed about 100 people who were trying to use the machine at the time. In short, the protection system on a typical multi-user machine is there to protect users from one another; it affords *some* protection to users against bugs in programs, but it would appear that the commercial software for the big machines is just as unreliable as the products for the little beasties we all know and love. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 The meek shall inherit the Earth--if that's OK with the rest of you chaps.
barnett@grymoire.crd.ge.com (Bruce Barnett) (08/10/90)
In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > There was a discussion a while back about the virtues of protected operating > systems. A number of people seem to believe that PCs in general, and > Macintosh in particular, will become much more reliable once they start > to enforce a separation between user-level and kernel-level code. I feel that the bigger problem MacOS faces is the need to reboot the machine to install certain pieces of software. On some of our boxes that server hundreds of users, the last thing we want to do is to reboot the machine. The same should be true of MacOS, but I don't believe that will happen for years, if ever. > Frankly, I'm a little skeptical. As a regular user of both a Mac and > a VAX/VMS cluster, I'd have to say that the relative frequency of > crashes of the two systems, leaving aside the times I crash either > one while debugging my own software, is something in the region of > 10:1. That is, it's not as much as 100:1. If you crash the system while developing unpriviledged code, then that is an indication the system has serious bugs in it. It is not an indication that protected mode is meaningless. I have installed hundreds of software packages as an unprivileged user. I cannot remember one case where this software crashed the machine. It might crash my account, but the other users were unaffected. There have been cases of user mode programs crashing a system. This always indicates a serious problem in the system itself. > In short, the protection system on a typical multi-user machine > is there to protect users from one another; it affords *some* > protection to users against bugs in programs, but it would appear > that the commercial software for the big machines is just as > unreliable as the products for the little beasties we all know and love. This I disagree with, for the above reasons. Installing/running priviledged software is another issue. Yes it can crash a system. But then this is not the case of system mode vs. user mode. If system mode software brings the system down, the code is buggy. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
mshappe@trumpet.cit.cornell.edu (08/10/90)
In <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: }Frankly, I'm a little skeptical. As a regular user of both a Mac and }a VAX/VMS cluster, I'd have to say that the relative frequency of }crashes of the two systems, leaving aside the times I crash either }one while debugging my own software, is something in the region of }10:1. That is, it's not as much as 100:1. } }Now, if it were 100:1, you could claim that a protected system is }truly wonderful, and would effect a great improvement in the reliability }of the system. But 10:1 is probably comparable to the ratio of crashes }that you would get between different Mac users running different }applications, or using the same applications in different ways. ... } }In other words, I don't think protected mode is worth it. }Even if you disagree with my numbers (feel free to come up ones }with some real evidence behind them, by all means), there are more }fundamental problems. Whew. I don't disagree with your numbers. You're probably correct--a more-or-less stable Mac system (ie. one with a limited number of inits, and those tried and tested) is not all that liable to crash. I disagree, however, with your characterization that this makes it not worth the effort of putting protected mode in. As a Unix-universe hacker as well as a Mac enthusiast, I can tell you that working with a system with the kernal running separately is an incredible boon--especially when reboot of a large system like Unix (or even init-heavy Mac systems) can take several minutes--minutes lost to productivity. Not to mention the fact that a crash that takes out everything is likely to scramble disk and data if the timing is wrong... }Consider a couple of Mac applications that I have installed on }my machine right now: After Dark and Adobe Type Manager. In a }protected system, would they be ordinary user-mode code, or would }they need to run in privileged mode? If they can run in user mode }without any special privileges, then any other user-level code }could use the same hooks, run amuck, and render my screen display }totally unusable. The kernel may still be running undamaged, but }as far as I'm concerned, my system has crashed. In answer to the primary question--I would say that any system "patch" such as ATM or After Dark--that is, anything with an INIT 31 in it, would become a part of the Kernel and therefore run in Protected/Priviledged mode. The reason for this is that the effect the ENTIRE system--not just one application. They are part of the "global environment", if you will, just as the OS and Toolbox are. If they ran as just another process--even one that other apps could get at (and with IAC, that would not be all that difficult)--then a crash of one of those processes would, as you have already said, hook into them and crash the screen. Background processes would run on, but the user interface would be useless, and ultimately, you'd have to reboot anyway. }On the other hand, if these two applications would need to run }privileged, then I would argue that a significant number of other }applications out there would also have reason to run privileged. }What good is a protection system with lots of exceptions to it? But are they exceptions? INITs, cdevs, rdevs, and the like are really a part of the system, once they run, even now. They are hooks and patches into and over what the OS and Toolbox normally do. For example, the WDEF INIT/cdev (not to be confused with the virus of the same name) patches the WDEF resource of the System, such that EVERY window that is opened in a MacStandard manner will adopt the "new" look (controlled by the cdev), rather than the MacStandard look. Why should this not run protected, then, when it is essentially becoming a part of the Toolbox? }Our VAXcluster runs several applications requiring some level }of privilege. For example, the TCP/IP product that we use, }called Multinet, loads itself into system memory as an extension }to the VMS kernel (analogous to TSRs under DOS, or INITs on the }Mac). A couple of months ago it hung; the rest of VMS kept running, }but all TCP/IP services became unusable. The only way to clear }the problem was to restart the system, which would have annoyed }about 100 people who were trying to use the machine at the time. But a program such as this HAS to run in Protected mode on a machine that supports such things in order to run properly. It is, as you said, a part of the kernel, once it's loaded (in much the same way that MacTCP can be considered part of the system once it's loaded). On a single-mode system like a Mac, a crash of the TCP drivers would have CRASHED THE MACHINE--and your 100 users would be VERY annoyed. At least in your case, a sysadmin can send a message announcing that the machine needs to be rebooted in 20 minutes so please save your work--because it was protected. If everything ran at the same level, a lot of people would have LOST THEIR WORK because of such a crash. (And yes, in the case of MacTCP bombing, I speak from experience) }In short, the protection system on a typical multi-user machine }is there to protect users from one another; it affords *some* }protection to users against bugs in programs, but it would appear }that the commercial software for the big machines is just as }unreliable as the products for the little beasties we all know and love. Granted. Which is exactly an arguement for protection. It doesn't just protect USERS from one another, but PROCESSES. Under MultiFinder (which will become the One and Only Way under System Seven), every app you launch is analogous to a UNIX or VMS Process. Without protection, if any one of those processes crash, you run the risk of the entire machine going Boom (true--it doesn't always happen. I would say a simple "Application Foobar Unexpectedly Quit (2)" is as frequent as a system crash). With protection, this would not occur. As MultiFinder becomes more and more a part of the Mac users's life, process protection will become vital to the stability of even a single user's environment. Or, at least, so I believe :-) }Lawrence D'Oliveiro fone: +64-71-562-889 }Computer Services Dept fax: +64-71-384-066 }University of Waikato electric mail: ldo@waikato.ac.nz }Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 }The meek shall inherit the Earth--if that's OK with the rest of you chaps. -- Mike Shappe (Uncle Mikey) Cornell Office of Information Technologies mshappe@{heights,oitnext}.cit.cornell.edu,mshappe@biar.uucp,mikey@amnesia.uucp "And so it goes, And so it goes. And so will you soon, I suppose" -- B. Joel
jazzman@claris.com (Sydney R. Polk) (08/11/90)
From article <1204.26c2fb48@waikato.ac.nz>, by ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University): > There was a discussion a while back about the virtues of protected operating > systems. A number of people seem to believe that PCs in general, and > Macintosh in particular, will become much more reliable once they start > to enforce a separation between user-level and kernel-level code. I would just be happy if I got an error when I balsted memory outside the application heap. I would estimate that fully 70% of my debugging time on the Mac is spent tracking down who is blasting memory where, whether it's me or the system of some bozo init that somebody has on there machine. Maybe it's nicer for the machine to limp along after somebody plugs a hole somewhere in a random data structure, but for debugging, it would be nice if I could tell immediately. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
carlo@osprey.cvs.rochester.edu (Carlo Tiana) (08/12/90)
In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >[Mac OS "only" crashes 10x as often as VMS, so protected OS would not be >worth it] flame on = Apple and DEC (a little) Well, YIKES! I would fault your so-called protected system here, rahter than putting up with crashing on both. Since it probably takes about 10x as long to reboot a VAX cluster than a Mac, I'd say that was a real nuisance to begin with. In any case I am amazed at how often you claim to crash your VAXen. I have worked on U*IX boxes much longer than on Macs and have *never* (as mere 'user') crashed one. I crach my Mac on at least a daily basis -- when developing on about a 10 minute cycle. In fact, this is the one thing I feel really strongly about with Macs. I think Apple should really get its act together; I spent over $7500 on my system, for all the advantages of using Macs that are so well known. But I really feel cheated in some ways. I sort of feel like the idea was good but the implementation sucks. What's 'friendly' about a system crash under Multifinder with 4 or 5 apps open and unsaved stuff in all of them?? In my experience of programming PC's I've never seen quirkiness such as this. I have helped many people purchase their home computers. I always evaluate their patience in dealing with things technological and if that is not above threshold I tell them that in all fairness, what you buy in ease-of-use of the interface, you lose in system crashes. If protected os's are the answer to this problem (though I believe more thorough testing should be, at least in principle), then by all means, Apple, go for it!!! I am not sure that I would advise anyone I call a friend to spend a lot of money on a Mac, given this kind of 'performance'! Carlo. carlo@cvs.rochester.edu
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/13/90)
Thanks to all those people who pointed out how reliable their UNIX systems were. Can any of them tell me: does your system run anything like Adobe Type Manager, or After Dark? Or (rummaging through this pile of software that I haven't looked at yet) QuicKeys, FileMagic or POWERmenus? Can you think of a way of implementing hooks for any of these so that a bug in them can't render the system entirely unusable? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 I'm tired of people calling me Quasimodo--it really gets my back up.
barnett@grymoire.crd.ge.com (Bruce Barnett) (08/13/90)
In article <1210.26c694ed@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > Thanks to all those people who pointed out how reliable their UNIX systems > were. Can any of them tell me: does your system run anything like > Adobe Type Manager, Yes. OpenWindows on a Sun supports scalable fonts. The standard configuration comes with 57 scalable fonts. > or After Dark? Several screen savers are available. > Or (rummaging through this pile of > software that I haven't looked at yet) QuicKeys, FileMagic or POWERmenus? Yes. Yes. Yes. I do not follow your point. What does this have to do with your point about protected mode vs. unprotected mode. The Mac has some great software. No one said otherwise. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
chewy@apple.com (Paul Snively) (08/14/90)
In article <8919@ur-cc.UUCP> carlo@osprey.cvs.rochester.edu (Carlo Tiana) writes: > flame on = Apple and DEC (a little) [body of flame deleted for brevity] Well, let's remember a few pertinent facts about the MacOS: 1) It was designed and implemented for a machine with 64K of ROM and 128K of RAM. 2) Not all Macs even have a hardware memory-management unit. Remember, the Mac started off life as a personal computer, not a workstation or what have you. It had a 68000, which doesn't even support an MMU. 3) While MultiFinder is pretty cool, it's also doing stuff that no tasking system should ever be asked to do! The MacOS was never intended to support multitasking, let alone protected address spaces. All things considered, I think we're doing ok. That doesn't mean that I wouldn't like to see a protected OS on the Mac. I would. It's just that once you had it, you wouldn't have what we think of as the "MacOS" anymore. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (08/14/90)
Various people said, ( sorry, lost the attribution line ) >> Adobe Type Manager, >Yes. OpenWindows on a Sun supports scalable fonts. The standard >configuration comes with 57 scalable fonts. > >> or After Dark? > >Several screen savers are available. > >> Or (rummaging through this pile of >> software that I haven't looked at yet) QuicKeys, FileMagic or POWERmenus? > >Yes. Yes. Yes. > >I do not follow your point. What does this have to do with your point >about protected mode vs. unprotected mode. You're obviously missing the point. What he meant to point out is that in a protected-mode environment it is very difficult for a user process to directly patch operating system calls, and he is arguing that the capability makes the Macintosh a much more easily customizable system. Note that I'm not sure how I feel about that argument, but you weren't answering his point. -- Mark Wilkins wilkins@jarthur.claremont.edu
gft_robert@gsbacd.uchicago.edu (08/14/90)
------- In article <9725@goofy.Apple.COM>, chewy@apple.com (Paul Snively) writes... [...] > >That doesn't mean that I wouldn't like to see a protected OS on the Mac. >I would. It's just that once you had it, you wouldn't have what we think >of as the "MacOS" anymore. Gee whiz, I thought that was the next cool great thing coming out with System "if you thought you waited for 7.0" 8.0! :-> So, will we have to wait for the 88k machines to get protected mem? Or will we in fact get it for the 68k Macs, but with the unfortunate side effect that the OS won't seem exactly like the Mac anymore: cat README, etc. :-> Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/14/90)
As quoted from <1210.26c694ed@waikato.ac.nz> by ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University): +--------------- | Thanks to all those people who pointed out how reliable their UNIX systems | were. Can any of them tell me: does your system run anything like | Adobe Type Manager, or After Dark? Or (rummaging through this pile of +--------------- Sneak a look at Mach's architecture. ptys and/or STREAMS drivers (assuming STREAMS tty drivers) can provide I/O mechanisms. I've plotted out some interesting stuff that uses STREAMS ttys; recently, I've encountered a similar mechanism using ptys (DG AViiON "editread"). STREAMS drivers would require something like Mach to make them completely safe, but the "editread" mechanism is done completely in a user-mode program. I dare say it wouldn't be that difficult to provide a configurable ATM-alike for X Windows, although I haven't yet gotten my hands on an X-capable system. I *know* After Dark can be done, and in user code. I had some stuff in Altos APEX (a Windows 2.11 interface to their UNIX boxes; they wouldn't listen to my pleas for a Mac version)-: which implemented screen saving from the host end by manipulating windows. "editread" is the equivalent of QuicKeys (not to mention an extended TextEdit and a few other things besides). I haven't heard of POWERmenus, so I can't say anything there. FileMagic --- again, I'm not familiar with it. If it's a StdFile extension, it's beyond ordinary UNIX *as currently distributed*, but the multiple file system handling of SVR3 and SunOS4 provides an opening... and, again, Mach has a few things to say on the subject as well. In any case, UNIX has the basic ability to do these things; however, it was designed for a different kind of user interface (it may not be the world's best user interface, but it *is* a UI) and therefore does not provide these capabilities as shipped. X Windows is a better comparison to what you're looking for, and (from what I know of it) it can accomplish many of the things you're looking for *in user code* and therefore without risking other processes (hence, users) on the system. ++Brandon -- Me: Brandon S. Allbery VHF: KB8JRR/KT on 220 (soon others) Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/14/90)
As quoted from <8099@jarthur.Claremont.EDU> by wilkins@jarthur.Claremont.EDU (Mark Wilkins): +--------------- | Various people said, ( sorry, lost the attribution line ) | >> Adobe Type Manager, | | >Yes. OpenWindows on a Sun supports scalable fonts. The standard | >configuration comes with 57 scalable fonts. | > | >> or After Dark? | > | >Several screen savers are available. | | You're obviously missing the point. What he meant to point out is that in | a protected-mode environment it is very difficult for a user process to | directly patch operating system calls, and he is arguing that the capability | makes the Macintosh a much more easily customizable system. +--------------- The point *he* was making is that all of this is done with USER-mode code and therefore can't crash the system.... ++Brandon -- Me: Brandon S. Allbery VHF: KB8JRR/KT on 220 (soon others) Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR
russotto@eng.umd.edu (Matthew T. Russotto) (08/14/90)
In article <1990Aug13.220852.10000@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: > in fact get it [protected memory] for the 68k Macs, but with the unfortunate > side effect that the OS won't seem exactly like the Mac anymore: > cat README, etc. :-> We already have that-- its called A/UX :-) :-) :-) (anyone know where I can get X-Windows 4 for less than the highway robbery price Apple is selling it for? Preferably on CD-ROM) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
PL430331@tecmtyvm.mty.itesm.mx (08/15/90)
I think that this problem should be solved in the same way that Apple solved
the problem of assigning system heap memory to the INITs: by setting a flag
within a resource (say, 'prot'). This way, a Init like AfterDark could run
under user mode, and another like Adobe Type Manager could patch the OS in
protected mode.
Perhaps the main danger of assigning INIT the permission to run privileged
instructions is: How can I be sure it is NOT a virus? (Just think about it!)
I thought the answer was: Run all Inits under user mode, and if they patch
system routines, let them have a way to tell the OS they're going to make
a correction, and, when the system call is made, the OS gives them control
to the patch routine, then back to protected mode. Now the problem is: How
can we accomplish this?
It would be safer to use levels of privilege, like in the Intel 386
(UGH! ARG!!).
And I think this discussion would be useless if the posibility of using
protected mode in the Mac wouldn't be real. When will Apple dare to make
this move?
Greeting from ITESM, Monterrey, Mexico,
your friends, Gabriel & Rael.tim@efi.com (Tim Maroney) (08/15/90)
In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Frankly, I'm a little skeptical. As a regular user of both a Mac and >a VAX/VMS cluster, I'd have to say that the relative frequency of >crashes of the two systems, leaving aside the times I crash either >one while debugging my own software, is something in the region of >10:1. That is, it's not as much as 100:1. "Leaving aside the times I crash either one while debugging my own software"? Lawrence, that's the whole point! The main user community clamoring for memory protection is software developers! I really don't like crashing my system hundreds of times during development. It leads to disk errors, it wastes a lot of time, it sometimes loses my work, it makes it impossible to trace many errors. How often have you crashed VMS while developing a user-space application without special privileges? Ever? I doubt it. Compare that to several times a day for developing an ordinary Macintosh application. Dividing by zero leaves an infinite difference between the two.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/15/90)
In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >I really don't like >crashing my system hundreds of times during development. It leads to >disk errors, it wastes a lot of time, it sometimes loses my work I gave up doing work on my development mac. All editing and other important things take place elsewhere. The source gets transferred to the mac only for compilation and testing. At least I can make notes and ponder my source while my mac clicks, buzzes, and reboots. I don't see how anybody can cope any other way. >it makes it impossible to trace many errors. No help here, of course. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
cantrell@Alliant.COM (Paul Cantrell) (08/16/90)
In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Frankly, I'm a little skeptical. As a regular user of both a Mac and >a VAX/VMS cluster, I'd have to say that the relative frequency of >crashes of the two systems, leaving aside the times I crash either >one while debugging my own software, is something in the region of >10:1. That is, it's not as much as 100:1. 1) A VAX cluster has *lots* more hardware to go wrong than a MAC, so some of those VMS crashes might be due to hardware trashing the system. Protected operation will only catch a few of those, the rest may well result in crashes. 2) A VAX cluster has *lots* more software to go wrong than a MAC. The kernel itself is much larger and more complex. The kernel is very asynchronous while the MAC OS is not. 3) A VAX cluster typically has *lots* more users than a MAC. This depends on how it gets used, but hundreds of users isn't uncommon for a cluster. Add all that up, and you would expect the VAX to be crashing a hundred or a thousand times as much as the MAC. There really isn't *that* much to go wrong with a MAC. They're pretty simple beasts. What's causing the VMS system to be so reliable? Partly the fact that a lot of the code gets run in non-kernel mode where errors don't take out the system in strange and mysterious ways (or worse, simply change some kernel data). Either that, or DEC builds software and hardware much more reliably than Apple. I don't really think that accounts for the difference... Paul Cantrell
austing@Apple.COM (Glenn L. Austin) (08/16/90)
dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >>I really don't like >>crashing my system hundreds of times during development. It leads to >>disk errors, it wastes a lot of time, it sometimes loses my work Try using Jasik's Debugger. Yes, I know that its expensive, but according to the docs, it allows you to debug in protected mode on a PMMU-available machine. -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
PAT@rcgl1.eng.ohio-state.edu (Patrick Plaisted) (08/16/90)
| In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: | >Frankly, I'm a little skeptical. As a regular user of both a Mac and | >a VAX/VMS cluster, I'd have to say that the relative frequency of | >crashes of the two systems, leaving aside the times I crash either | >one while debugging my own software, is something in the region of | >10:1. That is, it's not as much as 100:1. From my experience of using both Macs and VAXen often, if your ratio is only 10:1 then you have some serious setup problems with your VAX cluster. The VAX that I manage has crashed once in the last six months, and that was due to using some public domain kernal mode code (you get what you pay for :-) ) | | 1) A VAX cluster has *lots* more hardware to go wrong than a MAC, so some of | those VMS crashes might be due to hardware trashing the system. Protected | operation will only catch a few of those, the rest may well result in | crashes. | | 2) A VAX cluster has *lots* more software to go wrong than a MAC. The kernel | itself is much larger and more complex. The kernel is very asynchronous | while the MAC OS is not. | | 3) A VAX cluster typically has *lots* more users than a MAC. This depends on | how it gets used, but hundreds of users isn't uncommon for a cluster. | | Add all that up, and you would expect the VAX to be crashing a hundred or | a thousand times as much as the MAC. There really isn't *that* much to go | wrong with a MAC. They're pretty simple beasts. What's causing the VMS | system to be so reliable? Partly the fact that a lot of the code gets run | in non-kernel mode where errors don't take out the system in strange and | mysterious ways (or worse, simply change some kernel data). | [...] All that you say is true, but a comparison between the two operating systems is rather silly. VMS consists of some 5.5 million lines of code; Mac OS of a couple thousand. VMS is designed to be a robust, multi user operating system; Mac OS is for a personal computer. For all practical purposes, the only person that can crash a VAX should by your system manager. Anyone that knows a mac can crash it in about 30 seconds if they wish. They are in two completly different worlds. Not that I'm flaming Mac's (I really like them!), but the operating system just isn't that robust. Maybe when Mac's get real memory management in 7.0 things will be better. We can only hope... Pat =========================================================================== Patrick Plaisted |pat@agvax2.ag.ohio-state.edu System Programmer | or if you want to Ohio Cooperative Extension Service | torture me with unix: The Ohio State University |pat@klingon.eng.ohio-state.edu 2120 Fyffe Rd. Room #109 | Columbus, Ohio 43210 | (614) 292-4338 =========================================================================== I'm not quite sure who's ideas these are; I think they're mine...
barmar@think.com (Barry Margolin) (08/16/90)
In article <1990Aug14.010751.20050@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: >As quoted from <8099@jarthur.Claremont.EDU> by wilkins@jarthur.Claremont.EDU (Mark Wilkins): >| You're obviously missing the point. What he meant to point out is that in >| a protected-mode environment it is very difficult for a user process to >| directly patch operating system calls, and he is arguing that the capability >| makes the Macintosh a much more easily customizable system. >The point *he* was making is that all of this is done with USER-mode code and >therefore can't crash the system.... I think the Mac is currently more customizable, because it can be customized at any level the programmer is willing to deal with. Protected systems generally limit the places where customization may be applied. However, enabling memory protection doesn't mean that the system has to be fascist. There could be a system call that allows a user process to write anywhere in system memory. In this way, you don't prevent applications from customizing the system, they are simply forced to do it explicitly. This way, program bugs are unlikely to *accidentally* modify memory belonging to the kernel or other processes. The decision on whether to provide calls like this must be based on the intent of the memory protection. If it's just to keep applications from accidentally interfering with each other, this would work. On multiuser systems, however, memory protection is usually also intended to prevent malicious users from bothering other users, in which case such a system call is not usually a good idea (and then you start getting more complicated, by defining privilege levels and allowing some users to do it while preventing others). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
edwardj@microsoft.UUCP (Edward JUNG) (08/16/90)
In article <8099@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: [quotes deleted] > You're obviously missing the point. What he meant to point out is that in >a protected-mode environment it is very difficult for a user process to >directly patch operating system calls, and he is arguing that the capability >makes the Macintosh a much more easily customizable system. > No doubt that a non-protected environment is more easily hacked than a protected environment, where "hacked" here means "made to do things on behalf of ALL apps that the architecture did not originally allow". By definition non-protected systems are going to provide fewer hinders to hacking about, passing pointers among processes to share memory, writing into other processes' memory spaces, hooking the entire OS from under all apps, etc. You have to balance this against the flexibility of a virtual machine. Unix, for example, has been made to do quite a few things considering its 1960's heritage, and it too is a protected system. While Unix isn't exactly a VM, it is, for all intents and purposes, highly abstracted. Not as open as a non-protected system, but still quite able. And much safer. Newer OS that move more responsibility to user code allow a large degree of flexibility, even down to user-code VM pagers. The NeXT machine, for example, allows user code to do all those Mac-like things in a protected environment. > Note that I'm not sure how I feel about that argument, but you weren't >answering his point. > >-- Mark Wilkins > wilkins@jarthur.claremont.edu I don't think the point washes: that protected systems make useful tools *too* difficult to develop is untrue IMHO (note the "too"). Note: I am biased because my fx blew up on Monday and hosed alot of work. Multifinder has made the amount of potentially lost work much greater. I, for one, want a protected environment. Under OS/2, SunOS, or NeXT I may lose data in one crashing app, but virtually never all the running applications. This becomes more critical as machines become depended- upon for services or network-linked documents. Edward Jung Advanced Systems Architecture Systems Strategist Microsoft Corporation
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/16/90)
In article <5567@quanta.eng.ohio-state.edu> PAT@rcgl1.eng.ohio-state.edu (Patrick Plaisted) writes: >All that you say is true, but a comparison between the two operating >systems is rather silly. VMS consists of some 5.5 million lines of >code; Mac OS of a couple thousand. No, you're thinking of MS-DOS. The Mac OS is a heck of a lot bigger than 2000 lines (if you include the Toolbox, which you pretty much have to; in fact, since the mac doesn't have memory protection, pretty much every piece of software on it is part of the "operating system", but I digress). I'm sure you're right that VMS is much bigger than the Mac OS, though. >Not that I'm flaming Mac's (I really like them!), I'm not flaming VMS, either, though I would be MORE than happy to :-). >but the operating >system just isn't that robust. Maybe when Mac's get real memory >management in 7.0 things will be better. The memory management in 7.0 isn't going to help AT ALL. NONE. NOT A BIT. Any old application will still be able to step on anything tasty, anywhere. (Of course, the more memory you have, the less likely your software is to write on something dangerous when it starts dereferencing random pointers; but this will probably at least balanced by the VM system itself, which will have its own bugs.) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/17/90)
In <1990Aug14.010751.20050@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) says, in response to a comment by wilkins@jarthur.Claremont.EDU (Mark Wilkins): "The point *he* [i e I] was making is that all of this is done with USER-mode code and therefore can't crash the system...." Mark has got it right, and Brandon hasn't. My point was that, whether these things are done in user-mode code or not, they can still make the system unusable. A hook that allows replacement of the system text-drawing routines can, if misused, turn much of the display into garbage; a screen-saver hook can be used to destroy the display completely. And so on. Whether such behaviour is technically a "crash" or not is irrelevant. The end result to the user is pretty much the same. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 "Are you calling me a lawyer?"
drd@siia.mv.com (David Dick) (08/17/90)
In <1210.26c694ed@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Thanks to all those people who pointed out how reliable their UNIX systems >were. Can any of them tell me: does your system run anything like >Adobe Type Manager, or After Dark? Or (rummaging through this pile of >software that I haven't looked at yet) QuicKeys, FileMagic or POWERmenus? >Can you think of a way of implementing hooks for any of these so that a >bug in them can't render the system entirely unusable? The research operating system MULTICS included the concept of rings. Take the idea of two modes--user and system--and generalize it so that there is some number of modes > 2. The innermost ring would contain super-critical things like process scheduling and perhaps memory management. The next ring out might contain device drivers; further out rings containing things closer to user application programs. Outer-ring code would invoke inner-ring code in somewhat the same way system calls are done. (On MULTICS, ordinary subroutine calls would be done and the system would conspire to provide mode-changes the same way system-mode changes happen with system calls on most operating systems.) ATM or After Dark would operate in some intermediate ring. If they misbehaved, they could trash things in outer rings, but never those in inner rings. Some inner-ring code could be responsible for cleaning up after unfortunate events in outer rings. Even if a sophisticated facility like rings is not provided (and why they aren't I don't know--MULTICS had them almost 20 years ago!), a kernel can still provide protection by manipulating the address spaces while special-purpose things such as those you mention. In UNIX it could be done with special device drivers or additional system calls (e.g. to attach video ram to the code's address space). It's not as elegant and probably isn't practical for all uses, but it's still FAR better than the totally uncontrolled Mac environment of today. David Dick Software Innovations, Inc. [the Software Moving Company (sm)] "moving software to UNIX since 1980"
barnett@grymoire.crd.ge.com (Bruce Barnett) (08/17/90)
In article <1204.26c2fb48@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > In other words, I don't think protected mode is worth it. I disagree. In article <1252.26cbdffa@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > Mark has got it right, and Brandon [and Bruce] hasn't. My point was that, > whether these things are done in user-mode code or not, they can > still make the system unusable. A hook that allows replacement of the > system text-drawing routines can, if misused, turn much of the display > into garbage; a screen-saver hook can be used to destroy the display > completely. And so on. > Whether such behaviour is technically a "crash" or not is > irrelevant. The end result to the user is pretty much the same. You should realize that the "protection" in not "user" vs. "kernal". There are three levels of protection in most protected systems I use: 1) Kernal Protection 2) Window Manager Protection 3) Application Protection Given a stable OS and a stable window manager, no application should cause either the system or the window sessions to crash. If it does crash, then the software is immature. Changing the window environment can crash the session but not the OS. This is why such modifications are left to experts and commercial companies. INITs are changes to the window manager. They are a big headache today, and will continue to be a headache with a protected MacOS, because it is changing protected code. In that respect, Lawrence, you are correct. However, and this is the FIRST point, most of the Mac software today does not require modifications to the "common" toolkit. Assuming the Mac user has a very stable collection of INITs and CDEVs, the protected Mac should *never* crash. The SECOND point is: Not all applications require running in protected mode. While AfterDark/MacOS currently does, some windows systems do not require special privileges to execute a screen saver, or any other application you describe. It is even possible to kill your window manager, start up a different window manager with a completely different look and feel, and continue *without* interrupting the applications that are running. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
tim@efi.com (Tim Maroney) (08/18/90)
In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >>I really don't like >>crashing my system hundreds of times during development. It leads to >>disk errors, it wastes a lot of time, it sometimes loses my work, >> >>it makes it impossible to trace many errors. In article <1990Aug15.133346.18080@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >No help here, of course. How so? If a system gets big random chunks of its RAM overwritten, including debugger code, and then crashes requiring (or forcing) a reboot, then it's pretty hard to see where the error occurred. If memory protection suspends the application and breaks into the pristine debugger as soon as the bad memory write is requested, it's much easier to see what's going on.
tim@efi.com (Tim Maroney) (08/18/90)
In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >>>I really don't like >>>crashing my system hundreds of times during development. It leads to >>>disk errors, it wastes a lot of time, it sometimes loses my work In article <44005@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >Try using Jasik's Debugger. Yes, I know that its expensive, but according >to the docs, it allows you to debug in protected mode on a PMMU-available >machine. I've heard that it consistently crashes during demonstrations, slows down execution amazingly, and has an interface only slightly more friendly than MacNosy. No thanks.
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/20/90)
In <1990Aug17.133833.9024@siia.mv.com>, drd@siia.mv.com (David Dick) talks about an even more elaborate version of the user/supervisor mode division scheme, and illustrates some imaginative uses for it. Dear David, please reread <1252.26cbdffa@waikato.ac.nz>, where I tried to make clear a point I first raised in the second half of <1204.26c2fb48@waikato.ac.nz>. I am beginning to get the feeling that there is a distinct "timesharing mentality" which is being demonstrated by a large number of people, who have *great* difficulty appreciating that a protection hole is a protection hole, regardless of how you implement it. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 I never thought I'd agree with this statement I keep sending up, but: "To someone with a hammer, every problem looks like a nail."
bell@pyro.ei.dupont.com (Mike Bell) (08/20/90)
In article <1990Aug17.213243.6075@efi.com> tim@efi.com (Tim Maroney) writes: >In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >>>>I really don't like >>>>crashing my system hundreds of times during development. It leads to >>>>disk errors, it wastes a lot of time, it sometimes loses my work > >In article <44005@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>Try using Jasik's Debugger. Yes, I know that its expensive, but according >>to the docs, it allows you to debug in protected mode on a PMMU-available >>machine. > >I've heard that it consistently crashes during demonstrations, slows >down execution amazingly, and has an interface only slightly more >friendly than MacNosy. No thanks. ....But in some circumstances, it's the only thing that works. I used it a lot while working on a NUBUS card driver (always a FUN experience). It's also the only debugger that is upgraded (with docs) every few months. I actually find Debugger's interface to be better than Macsbug. Mike Bell -- ******************************************************************************** Mike Bell Internet: mike_bell@zip.ei.dupont.com Senior Engineer CSNet: BELLMA%ERVX01@dupont.com DuPont Electronic Imaging Applelink: D2747 Core Technology Group MacBLITZ..... When you feel the need for speed.......... ******************************************************************************** --
Garance_Drosehn@mts.rpi.edu (Garance Drosehn) (08/21/90)
In article <1269.26d02a24@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > In <1990Aug17.133833.9024@siia.mv.com>, drd@siia.mv.com (David Dick) > talks about an even more elaborate version of the user/supervisor > mode division scheme, and illustrates some imaginative uses for > it. > > Dear David, please reread <1252.26cbdffa@waikato.ac.nz>, where I tried > to make clear a point I first raised in the second half of > <1204.26c2fb48@waikato.ac.nz>. I am beginning to get the feeling > that there is a distinct "timesharing mentality" which is being > demonstrated by a large number of people, who have *great* > difficulty appreciating that a protection hole is a protection hole, > regardless of how you implement it. In my experience, a number of problems with the INITs/cdevs on the Mac have nothing to do with the function they are performing. Consider, for instance, a screen saver. Now it is true that a screwy screen-saver could cause a problem on any system, but on a decent system the likely problems will be in screen-saving. Ie, the screen goes black and you can't get it back so you have to reboot. On any system this may require a reboot, but once you reboot you are bound to think "Hey, this just *might* be the fault of the screen saver". The headache with the current Mac system is that you have to play a guessing game as to what utility is causing any given bug. Go an tell any Mac application developer that they have a problem in their application. The first thing you'll get in reply is a request for every INIT and cdev that you have, including ones that are not even remotely connected to the problem you're seeing. And indeed, there are plenty of cases where INITs which are doing one thing are causing problems in areas not even remotely connected to what they are doing. This is a Bad Thing (tm). Garance_Drosehn@mts.rpi.edu ITS Systems Programmer Rensselaer Polytechnic Institute; Troy, NY. USA
jay@argosy.UUCP (Jay O'Conor) (08/21/90)
In article <1990Aug20.121633.8714@pyro.ei.dupont.com> bell@pyro.ei.dupont.com (Mike Bell) writes: >In article <1990Aug17.213243.6075@efi.com> tim@efi.com (Tim Maroney) writes: >>In article <1990Aug14.200525.20562@efi.com> tim@efi.com (Tim Maroney) writes: >>>>>I really don't like >>>>>crashing my system hundreds of times during development. It leads to >>>>>disk errors, it wastes a lot of time, it sometimes loses my work >> >>In article <44005@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>>Try using Jasik's Debugger. Yes, I know that its expensive, but according >>>to the docs, it allows you to debug in protected mode on a PMMU-available >>>machine. >> >>I've heard that it consistently crashes during demonstrations, slows >>down execution amazingly, and has an interface only slightly more >>friendly than MacNosy. No thanks. > > > > > ....But in some circumstances, it's the only thing that works. I used >it a lot while working on a NUBUS card driver (always a FUN experience). >It's also the only debugger that is upgraded (with docs) every few months. >I actually find Debugger's interface to be better than Macsbug. Sometimes, it's the only thing that _doesn't_ work! Not too long ago, I had a problem in a notification manager callback routine. I discovered that this routine is called during SystemTask or WaitNextEvent. Since The Debugger makes one or the other of these calls (I don't recall which), The Debugger wouldn't debug my routine. It considered to be running during the operation of The Debugger itself, not during the running of the program under test. In all fairness, this is the first (and only) time The Debugger has failed me. It makes short work of bugs that are extremely painful to catch in any other debugger. Despite it's shortcomings (price, interface, etc), I still wouldn't be without it. Jay O'Conor jay@maspar.com
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/22/90)
In <6S*%M~$@rpi.edu>, Garance_Drosehn@mts.rpi.edu (Garance Drosehn) says, in response to my flame about protected mode not having anything to do with the protection loopholes required to support screen savers and the like: "In my experience, a number of problems with the INITs/cdevs on the Mac have nothing to do with the function they are performing... Now it is true that a screwy screen-saver could cause a problem on any system, but on a decent system the likely problems will be in screen-saving. Ie, the screen goes black and you can't get it back so you have to reboot... [so] you are bound to think 'Hey, this just *might* be the fault of the screen saver'. "The headache with the current Mac system is that you have to play a guessing game as to what utility is causing any given bug. Go an tell any Mac application developer that they have a problem in their application. The first thing you'll get in reply is a request [to remove] every INIT and cdev that you have, including ones that are not even remotely connected to the problem you're seeing." You have a point. The problem, of course, is that the Mac system has no explicit provision for a hook such as a screen saver (or most of the other odd INITs and cdevs that people collect), so the beastie has to insinuate its little tendrils into all kinds of corners of the system in order to perform its function in a useful fashion. One could argue that a protected system could provide well-defined hooks precisely for functions such as these. The system may not be totally reliable, but it should be better than the Mac is now. I can't help feeling, though, that a lot of the fun goes out of it once you do this. A major part of the PC revolution generally has been getting computers to do things that no one, least of all the veterans of the "big" machines, could have imagined. Sure, you can provide hooks to support all the sorts of add-ons we currently know about. But what about the sorts of add-ons we *don't* yet know about? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 "...so she tried to break into the father bear's computer, but it was too hard. Then she tried to break into the mother bear's computer, but that was too easy..."
ts@cup.portal.com (Tim W Smith) (08/24/90)
The Callan Data Systems Unistar 200 I used to have had only a 68000 and supported an MMU quite well. A whole bunch of other 68000 systems of the same vintage also supported MMUs quite well. On the other hand, Callan and most of those other companies are out of business now...I don't know what that means but it seems somehow significant. Tim Smith
ts@cup.portal.com (Tim W Smith) (08/24/90)
The MacOS only has a couple of thousand lines of code? Man, I'm glad you don't do the estimates of project size where I work! :-) Tim Smith
philip@pescadero.Stanford.EDU (Philip Machanick) (08/25/90)
In article <33164@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: > The Callan Data Systems Unistar 200 I used to have had only > a 68000 and supported an MMU quite well. A whole bunch of > other 68000 systems of the same vintage also supported > MMUs quite well. > There was a discussion of this on comp.arch a while back. I don't remember the details, but it wasn't trivial. The problem is the 68000 doesn't keep enough state to restart some instructions that may be interrupted by a page fault. Some solutions included tricks like a second 68000 - it didn't sound to me as if one could simply tack on an MMU and get paging, the way you can with a 68020 (well, if assuming getting the software side to work is simple...). Philip Machanick philip@pescadero.stanford.edu
ts@cup.portal.com (Tim W Smith) (08/29/90)
In fact, it is trivial to use an MMU with a 68000. Virtual memory is the thing that is not trivial. Most of the discussion here about the possible need for an MMU was related to protection issues, which are independent of virtual memory. You can even do dynamic stack growth on the 68000. The trick is to get the compiler to generate a "tst.b (a7)" instruction after the link instruction in function headers. The bus error handler can without too much work detect this and grow the stack. In summary, a plain 68000 can easily support an MMU for protection. With a slight amount of work in the OS and the compiler, it can also support dynamic allocation of stack space. You need gross hacks, however, to get full virtual memory. Tim Smith
lsr@Apple.COM (Larry Rosenstein) (08/29/90)
In article <33355@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >In fact, it is trivial to use an MMU with a 68000. Virtual memory >is the thing that is not trivial. Most of the discussion here >You can even do dynamic stack growth on the 68000. The trick is >to get the compiler to generate a "tst.b (a7)" instruction after The Lisa used a 68000 and had an MMU. It did the dynamic stack expansion in the way you describe. It also handled demand loading of code segments by limiting the set of instructions used to branch into a segment, and figuring out how to restart those particular instructions. It wasn't possible to do this with data segments, because they could be referenced by almost any instruction. So the application program had to explicitly map/unmap the program's data segment(s) in to memory. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
slumlord@slum.MV.COM (Laird Heal) (09/06/90)
>In article <33164@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: >> The Callan Data Systems Unistar 200 I used to have had only >> a 68000 and supported an MMU quite well. A whole bunch of >> other 68000 systems of the same vintage also supported >> MMUs quite well. >> >There was a discussion of this on comp.arch a while back. I don't remember >the details, but it wasn't trivial. The problem is the 68000 doesn't >keep enough state to restart some instructions that may be interrupted >by a page fault. Some solutions included tricks like a second 68000 - >it didn't sound to me as if one could simply tack on an MMU and get paging, >the way you can with a 68020 (well, if assuming getting the software side >to work is simple...). > >Philip Machanick >philip@pescadero.stanford.edu The second 68000 could have been any processor to hold the first 68000 in a wait state while it obtained memory referenced by the particular address and read it from disk if necessary. You cannot restart a 68000 instruction due to the preincrement-postdecrement addressing modes, which make it well nigh impossible to determine what the value of the registers were when the instruction began. The 68010 solved this by pushing a few more bytes on the stack when servicing an interrupt. The 68020 and later began to utilize the previously-illegal "F-line" op codes, which are reserved for Motorola coprocessors. There are some FPU (68881) emulations of the 68020 for the 68000, and no reason that an MMU emulation could not be written - I would guess that it is little more than cleaning up from the ILLEGAL trap and writing to the address of the coprocessor. However, why bother? From a hardware standpoint it is just as easy to add a 68030 as a 68551, and from a software standpoint that is MUCH easier. Laird Heal laird@slum.MV.COM (Salem, NH) (603) 898-1406 -- Laird J. Heal {root, slumlord, laird}@slum.MV.COM (Salem, NH) (603) 898-1406