🚀 go-pugleaf

In article <1989Oct17.045410.399@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>>In article <6535@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>>>About the only hardware feature I used to pray for was "breakpoint at
>>>data address". ...

>The 80386 can trap up to four
>memory addresses, separately monitoring each for fetch, read, or write.
>When this feature is in use your program runs slower, but it's a heck of
>a lot faster than instruction at a time tracing.

Hmm, I wonder how much slower?

The above quote from my posting leaves off the comment that it can be
done *without* special hardware features. In particular, the infamous
trap-after-every-instruction feature is a bad idea, because this
"hardware assisted" method is sooo slooowwww.

1) I believe that Encore's debugger simply has a spare processor
watch the location.

2) A compiler generating debug code, can put a special call at the
front (and rear) of each subroutine. The debugger provides the
routine that is called: if you ask to have a location monitored, then
that's what the routine does. As debug services go, this takes very
little space and very little time - especially on machines with
lightweight call instructions. Admittedly, it can only say "the
variable changed in procedure foo, between its call to baz and its
call to bletch".  But, when I used it, that was great information.

3) The debugger could protect the variable's page, and catch the page
faults. Admittedly, a particularly popular page could cause a
performance problem. However, several times, I was looking for one
wild dereference into maybe four megabytes of tree. On a VAX, that
one locked page would have taken up a whole 0.0001 of the address
space.

My point: there are a lot of ways to skin a cat, and extra hardware
is usually only one of them.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science