Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.misc Subject: Re: True Multitasking Message-ID: <18623@cbmvax.commodore.com> Date: 6 Feb 91 16:48:10 GMT References: <42598@nigel.ee.udel.edu> <678@tnc.UUCP> <186@lsw.UUCP> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 62 In article <186@lsw.UUCP> gjc@lsw.UUCP (Greg) writes: >In article , mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >> That's one reasonable definition of "real" computers - that the system >> crashing is considered to a system problem, and not an application >> problem. >Excuse me?? How can a programmer, who is human, possibly account for >all possible contingencies??? What Mike is alluding to here is that an operating system, with the proper hardware support, can be written to trap and deal with programming errors. Your OS needs two basic features -- a per-task MMU context, and resource tracking, to do this correctly. Basically what happens is this: when a task context changes, a new MMU table is referenced a the user level. This table grants read/write permission to the memory resources owned by the new task, possibly read-only permission to system global resources, and makes any other memory access an error. Along with this, the system software tracks every memory or allocation made by the task. Should the task happen to access something it doesn't own, the MMU will cause an exception, calling up an OS control program that knows how to free up whatever the errant task has allocated and then eliminate the task itself. In the AmigaOS, resources are mediated by the OS, but it's up to each application to free them, and there's no way for the OS to know just what any application has allocated. Additionally, the OS doesn't manage a per-task MMU context (strangely enough, the majority of Amigas don't have MMUs), so hardware supported error trapping at present is a developer tool, not part of the general OS. In most cases, it's much better for the OS to handle resource tracking, just as it handles resource allocation, graphics, filesystem, etc. >Does this mean that every time an application crashes your Amiga/Mac >that the system designers are at fault just because some funky programmer >who doesn't know what he's doing wrote some strange out-of-this world >program?? What this says is that, had the system been designed differently, bad programming would not crash the system, just the application. You would also need an A2500/20 at the least to run the system. Ideally, the fact that the OS doesn't afford this protection will, in the long run, provide us with better quality applications. Since it's far more important to avoid bugs on an Amiga application, you tend to see these applications written more carefully than the typical protected-OS application. Because the very nature of the AmigaOS makes a great number of bugs obvious, whether in a crash or trapped by a development tool. UNIX, for example, can very easily hide a large number of different bugs, many of which result from the sloppy programming style popular on these systems (some of the GNU code is a good example); ints instead of pointers, macros where you should have a typedef, the assumption of near infinite memory availability, the list goes on. Obviously, a fatal bug in a UNIX program is less annoying than a similar one on an Amiga system. But that's kind of like saying that smashing up your car near a hospital is less annyoing than doing it out on a deserted road in the middle of the Pine Barrens. Proper methodology, whether driving or programming, avoiding the catastrophe in the first place, is best of all. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett