Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!njin!princeton!phoenix!mbkennel From: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) Newsgroups: comp.sys.mac.programmer Subject: Re: LSC 3.0 critique (long) Message-ID: <3784@phoenix.Princeton.EDU> Date: 28 Sep 88 03:06:10 GMT References: <2367@munnari.oz> <5453@hoptoad.uucp> Reply-To: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) Organization: Princeton University, NJ Lines: 67 In article <5453@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >> If there is some way on the Mac to ensure you never write to >other applications' memory during development, I sure would love to hear >about it, as would the validation theorists working on SDI. Saying "You've >got to be more careful with dangling pointers" is like saying "Be careful >whose car you hit." If you can help it, you won't hit anyone's. If you >can't, there isn't much opportunity for choice in the matter. > >As development environments go, LSC 3.0 does have some unusual virtues. >But its flaws are brain-damaged, unavoidable, and extremely annoying. >-- >Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Yes, there is a way that you never write to other application's memory: It's called hardware memory protection. You don't think that a multi-user computer can afford to crash whenever people dangle their pointers? The bottom line is that each process gets its own virtual address space. The totality of all processes address spaces get mapped on to the physical memory space, or possibly, disk sectors on a paging volume. Any attempt to write to "unauthorized" memory locations generally causes an operating system trap. In such a system, a chip sits in between the CPU and the memory, translating "virtual addresses" (what the program running on the CPU sees) to actual physical addresses of real memory. Unfortunately, most Macintoshes dont' have such a beast. Only the Mac II can be so equipped (it does not come standard) with a PMMU (paged memory management unit). You need this to run A/UX. The 68030 has the equivalent of the 68851 PMMU built-in. Presumably, the MacOS will eventually modified to provide inter-process memory protection (there's then no reason not to add in true pre-emptive multitasking and virtual memory), but this could be a major headache considering it's very hard to retro-fit it in and still maintain compatibility. For example, I wager that many commercial programs twaddle with low memory globals in various evil ways. Presumably, ina protected memory system, these globals would be protected from writing by all processes except the operating system, because changing them accidentally can easily produce a system crash. Back to program development: I'm sure that, when implemented, hardware memory protection will catch _tons_ of bugs in many programs: whenever you dereference a bad pointer and trap, you could easily make the debugger point at the very instruction that got screwed up. (This is done on virtually all "large" systems--Unix, and VMS for example. I'm not sure about OS/2, but if OS/2 were written for a 80386 instead of the god-awful 286 it could easily do this.) But for now, there is no real practical way to prevent your program from trashing any part of memory. LSC could, however _detect_ that its internal structures and the project file have been corrupted by computing a CRC checksum on various segments, for example, and then automatically re-loading those that have been trashed. Matt Kennel mbkennel@phoenix.princeton.edu