Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!ncrlnk!ncrcce!pasek
From: pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Protected mamory (SIC)
Summary: Who needs it ?
Keywords: Memory protect, storage keys
Message-ID: <1292@ncrcce.StPaul.NCR.COM>
Date: 18 May 89 19:35:41 GMT
Expires: 31 May 89 04:00:00 GMT
References: <1989May11.193812.2552@cs.rochester.edu> <8288@fluke.COM>
Reply-To: pasek@c10sd3.StPaul.NCR.COM (M. A. Pasek)
Followup-To: comp.sys.mac
Distribution: na
Organization: NCR Comten, Inc.
Lines: 34

In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
>In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes:
>>Protection issues needed to support multiple users aren't an issue with
>>single users.
>That's hard to swallow.  So it isn't an issue that a bug in my word processor
>can crash my machine?  Taking my spreadsheet, drawing program, and everything
>else with it?  I would personally (almost!) trade all the new features in
>System 7.0 for memory protection.

I must agree with Brad (sort of).  Where you NEED memory protection is where 
there may be MULTIPLE programs that have a GOOD probability of failing, and
where that failure CANNOT be tolerated.  If you choose to use a word processor
that continually crashes your system, then you MUST be prepared to tolerate
the outages.  

The big reason that I see for NOT doing memory protection is the expense, both
in hardware AND software.  The only way to do TRUE memory protection is to
provide each application with a unique storage key.  The storage key of the
current application is then matched with the storage key of the memory which
the application is trying to access, and if they don't match, the application
the "unexpectedly" quits.  The expense in hardware is adding the storage
key memory and the comparison logic.  The big expense in software is in doing
I/O.  For the most part, all data to be transferred in/out of the system would
have to be COPIED from/to the application memory space by the OS, before/after
the I/O occurs.  This would especially be true for AppleTalk, since there is
no way to know the socket (application) that the data is destined for until
after it is received.

Personally, I'd rather see memory with parity (or better yet, ECC) before
I would even WANT memory protection.

M. A. Pasek          Switching Software Development         NCR Comten, Inc.
(612) 638-7668              CNG Development               2700 N. Snelling Ave.
pasek@c10sd3.StPaul.NCR.COM                               Roseville, MN  55113