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