Path: utzoo!censor!geac!jtsv16!uunet!cbmvax!mks
From: mks@cbmvax.UUCP (Michael Sinz - CATS)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MutualExclude for Gadgets
Keywords: Amiga MutualExclude
Message-ID: <7970@cbmvax.UUCP>
Date: 22 Sep 89 12:55:31 GMT
References: <1849@cbnewsd.ATT.COM> <125013@sun.Eng.Sun.COM> <7964@cbmvax.UUCP> <125083@sun.Eng.Sun.COM>
Reply-To: mks@cbmvax.UUCP (Michael Sinz - CATS)
Distribution: usa
Organization: Commodore Technology, West Chester, PA
Lines: 70

In article <125083@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <7964@cbmvax.UUCP> mks@cbmvax.UUCP (Michael Sinz - CATS) writes:
>>Gee, Chuck, you didn't really say that did you?  Location 0 is undefined
>>and can contain any value, including ODD values.  (In fact, early A590
>>drives placed an odd value at location 0)  ;-)
>
>Actually I did say it, and what's really funny is that Commodore dug the
>exact same hole that the VAX implementation of UNIX had. *0 == 0. And
>what is one of the reccommended *diagnostics* of the Amiga ? Hmmm? It's
>MemWatch trying to guarantee that *nothing* ever writes to low memory.
>Endorsed by none other than C/A itself.

Ah, but C/A also has this wonderful MemMung program that trashes memory that
is FreeMem'ed (to find all those uses of memory that has been freed) and also
changes *0 to a large ODD value in the hopes that it will cause some error to
show up in your program.  This *IS* the recommended way to test *ALL* software
on the Amiga that runs within the bounds of the system.  MemWatch is also
important, and endorsed by C/A but not for the protection of *0 but for the
protection of *4 (AbsExecBase) and the rest of the interupt and exception
vectors.  In most any program, the writing to those locations is an error
(even writing into *0) and MemWatch helps you find these.

> ... And even your comment above
>about how the 590 *used* to write to location 0, but doesn't now implies
>that someone convinced you it was a bug too.

The reason this changed is because the driver that was in the AutoBoot
A590 had not be re-assembled without the debugging code, part of which hit
location 0 with a special code that our testers could play with.  It was
more for the fact that we wanted to speed up the code (no more stores into
*0) and reduce its size than the fact that *0 != NULL broke people.  (Even
though that also was a reason :-)

>
>#define RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE
>Depending on implementation peculiarities in any C program
>(especially that dereferencing a NULL pointer will point at a 0) is a
>major no-no. 
>#endif
>

#define WHAT_IS_THE_REAL_RULE \
	Read_and_Understand(Chuck,RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE)

    [... deleted stuff ...]
>
>So in summary, everyone may agree that looking at *0 is a bug but you will
>have a difficult time justifying breaking programs that might depend on 
>this behaviour in the future given your implicit support in the past.

While I will not say that *0 will or will not remain 0, it is *MY* view
that we should slowly work to changing it to some large ODD random number.
(Installed at BOOT time...)  It may not happen in 1.4, but as we continue
to push developers to write better code and use the debugging tools such as
MemMung and MemWatch 

>
>--Chuck McManis
>uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
>These opinions are my own and no one elses, but you knew that didn't you.
>"If I were driving a Macintosh, I'd have to stop before I could turn the wheel."


/----------------------------------------------------------------------\
|      /// Michael Sinz -- CATS/Amiga Software Engineer                |
|     ///  PHONE 215-431-9422  UUCP ( uunet | rutgers ) !cbmvax!mks    |
|    ///                                                               |
|\\\///          When people are free to do as they please,            |
| \XX/                they usually imitate each other.                 |
\----------------------------------------------------------------------/