Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!flatlin!tpki!kris
From: kris@tpki.toppoint.de (Kristian Koehntopp)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Letter to Commodore
Message-ID: <4498@tpki.toppoint.de>
Date: 16 Jun 91 11:08:11 GMT
References: <177458@netw23.uucp> <1068.285530d3@vger.nsu.edu>
Organization: Toppoint Mailbox e.V., Kiel, BRD
Lines: 62

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 will in no way slow down system performance, if
implemented properly. If you are going to allocate your memory in 16 byte
chunks (as some versions of microemacs do), you will probably feel a
performance impact, but any sane application will notice no difference,
since it allocates memory and other system ressources in larger chunks or
for longer times.

Resource tracking will probably cost you some memory, but this is no longer
an excuse for leaving out avital function of an operating system these days.

>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.  

Stability of an operating system does not help, when the applications are
not stable and have no way of leaving gracefully, since there is no
ressource tracking. And remember: One unstable application out of the many I
run simultaneously is enough to force a reboot. When I am working with a
machine, it is most likely that these applications work together on a
certain set of files. If an Amiga application crashed, its file locks are
not released and I cannot continue my work until I reboot.

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.

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.

>With the price of memory dropping like dirt what would be the real
>advantage to this?  The only things I can think of is handling large
>24 bit graphics data and perhaps being able to run numerous multi-megabyte
>applications.  

The advantage of virtual memory is: You have it immediately when you need
it, even if its slow and need not run out and buy these little black silicon
buggies. You can do your work (perhaps dtping a large book) in small,
manageable portions on your small machine and then run one large, but slow,
production run on this same machine without being forced to increase your
amount of real memory.

Kristian

Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689
"Painless installation."
	-- OS/2 1.3