🚀 go-pugleaf

In article <630@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes:
>>Ummm, it is ALWAYS my GOAL to have a bug free program.  As such, as soon as
>>someone reports a GURU or bug to me, I fix it and give the fix to everyone
>>with a copy of the program.  I do NOT blame the OS for my bug, nor believe that
>>the OS should be modified in order to "put up" with errors in _my_ code.
>>
>>						-- Kevin --
>
>My point is an issue of robustness.  Give someone a computer, and the next
>thing you know, they want to write a program on it ;).  Every time you go
>through the program development process, you have to deal with bugs in your
>code.  Often, these bugs are of a catastrophic nature.  I think that expecting
>the OS to deal with programs that experience such bugs in a graceful manner
>is not unreasonable.  I have been taught that program robustness (in dealing
>with user input and environment conditions) is nearly as important as program
>correctness.  Should an OS be held up to any less of a standard?
>
>I don't blame any OS for bugs introduced by *my* code.  But I do believe that
>an OS should be as robust as possible in dealing with what a user program
>might do.
>
>
>>Kevin Klop		{uunet|rutgers|amiga}!cbmvax!kevin
>>Commodore-Amiga, Inc.
>>
>>	``Be excellent to each other.''
>>		- Bill and Ted's most excellent adventure
>>
>>Disclaimer: _I_ don't know what I said, much less my employer.
>
>
>Dave Schaumann		| You are in a twisty maze of little
>dave@cs.arizona.edu	| C statements, all different.



The problem with this is the difficulty in a non memory protected model.
There is nothing to stop the user program from trashing system structures,
passing pointers that ostensibly point to buffers and actually point to
program code, etc. to the operating system, nor is there any way to stop
a program from trashing some OTHER program's code and data.

"So put memory protection in" sounds like a possible answer, but has been
hashed over and over again, this is no easy task.  The ramifications are
pretty far reaching and too detailed for me to get into now.

Ditto for resource tracking so that memory, devices, etc. are freed when a
program exits.  I have more than one program that opens something and then
passes the IO request to some OTHER task.  The original task then exits.
I certainly do NOT want the OS closing that device or deallocating the IO
request memory on me.

The question you raise, while a valid concern, is a tough one.  How much
are we willing to trade off?  Do we need to put an MMU in the A500s and
thereby raise the price of them significantly?  If not, then we need
two (or more) operating systems.  One to deal with MMU systems and one that
doesn't.  The two OSs would be VERY dissimilar, and would thereby at least
double the R&D load here at Commodore.

				-- Kevin --