Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.misc Subject: Re: Letter to Commodore Message-ID: Date: 17 Jun 91 16:59:35 GMT References: <177458@netw23.uucp> <1068.285530d3@vger.nsu.edu> <4498@tpki.toppoint.de> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 54 In-Reply-To: kris@tpki.toppoint.de's message of 16 Jun 91 11:08:11 GMT In article <4498@tpki.toppoint.de> kris@tpki.toppoint.de (Kristian Koehntopp) writes: manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >Though I would like to see resource tracking, it would really hurt the >performance of the Amiga. If it were implemented, I would like it to >be able to be turned off via preferences. Go and see OS/9 on an Atari ST. OS/9 is an operation system with ressource tracking on a machine similar to the Amiga in performance. OS/9 is small and neat and is even fast enough for realtime applications. Resource tracking isn't complete on OS/9. There are a few things that manage to get missed. Nor does OS/9 have the amount of process interconnnectedness and resource sharing that the Amiga has. >Talk about abandoning the A500/A1000/A2000! To do effective memory >protection would require the MMU of a 68020/68030. To be honest >however, the Amiga operating system is very stable (certainly 2.0 is!) >and this feature would really be the most effective on a developers >machine. Memory protection will help in creating applications, that are reliable even on systems without this protection, since many bugs are revealed, that might have slipped through otherwise. Actually, the developers tools on the Amiga already provide better facilities than protected environments. The protected environments I'm used to don't have things to scratch registers after system calls, don't have tools to verify memory allocations/frees and that you didn't write past the ends of an allocation in production code. Some of them don't even break when you read through a null pointer. But considering the internal operation of the Amigas OS, I guess, of all listed features, memory protection will be the hardest to implement. Even for well behaved applications it is common to forbid() and trace down some internal operating system structures and then to permit() again. A system with memory protection should offer an interface with function calls to retrieve all publicly available information about internal structures and hide the rest. The internal operation of the OS is a problem, but that's not the real one. Remember that all those lists are dynamically allocated, in small pieces. At least, they're small compared to the MMUs page size. You either wind up wasting large chunks of memory (both virtual and real), or rewriting the list management routines to know about the MMU page size. I don't know of a way to do this that won't fragment memory pretty badly.