Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 exptools; site ihlpl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!ihlpl!res
From: res@ihlpl.UUCP (Rich Strebendt @ AT&T Information Systems - Indian Hill West; formerly)
Newsgroups: net.arch
Subject: Re: Where to do stack checking, etc.
Message-ID: <335@ihlpl.UUCP>
Date: Tue, 10-Sep-85 21:55:03 EDT
Article-I.D.: ihlpl.335
Posted: Tue Sep 10 21:55:03 1985
Date-Received: Wed, 11-Sep-85 08:07:35 EDT
References: <796@kuling.UUCP> <1713@orca.UUCP> <1599@peora.UUCP>
Organization: AT&T Bell Laboratories
Lines: 44

> > The MMU is the answer.
> 
> I disagree with this.  Unless you design your microprocessor architecture
> from the beginning to require an MMU.
> 
> I was thinking about this question this weekend while trying to debug two
> very frustrating errors in a C program I was writing on my IBM PC (a UUCP-
> interfacing mailer).  There were two things badly needed.
> 
> 1) The ability to trap when JUST ONE particular address was generated as a
> data reference.  

I agree with the usefulness of this ability -- though I would not limit it to
JUST ONE of anything.  I prefer the trap setting ability I had years ago
working with IBM TSS.  There were three types of traps that I found very useful
in debugging a large program:

	a) Trap on a data store into any location in a specified range.
	Trapping on stores to locations in the range 0-256 often caught stores
	through null or nearly null pointers.

	b) Trap on an instruction fetch from any location in a range of
	addresses.  Very handy for catching a wild branch.

	c) Trap on any change to a specified register.  Handy to monitor
	returns from subroutines (R13 changed, I think -- it has been a while!)
	to find out whither they were returning -- or when the return address
	was being clobbered.

> The reason I say I disagree with the "in the MMU" approach is that
> currently most people treat MMUs as optional devices.  This means that any
> application in which you use a microprocessor but don't use an MMU won't
> have access to such facilities; and I think that for microprocessors, the
> non-MMU applications probably far exceed the ones that use MMUs (I'm
> referring here to the use of microprocessors in controllers, etc.).

I strongly agree.  I am developing firmware (board resident software) for a
controller.  All addressing is done on-board without an MMU.  The
stack-overflow exception has helped catch and make known a couple of bugs.  The
trap facilities above would have made finding a couple of others a good bit
easier.

					Rich Strebendt
					...!ihnp4!iwsl6!res