[prev in list] [next in list] [prev in thread] [next in thread] 

List:       classiccmp
Subject:    Re: Suggestions Appreciated for a Program Counter History Log
From:       "Jerome H. Fine" <jhfinedp3k () compsys ! to>
Date:       2013-08-28 11:31:12
Message-ID: 521DDF80.8040600 () compsys ! to
[Download RAW message or body]

 >Jay Jaeger wrote:

> Suggest you only capture when the PC changes thru a jump or interrupt.
>
> I recall working with a machine that did that in hardware, but I don't 
> recall which one it was.

Actually, most of the time I run my RT-11 programs using the
Ersatz-11 Emulator.  At one point, I actually took my SCSI
hard drive from the PDP-11 and attached it via a 50 pin cable
to a host adapter on a Pentium III running Windows 98SE.

The only real difference was that the CPU runs 15 times faster
than a PDP-11/93.  The disk drive speed was still the same.

I still run on that Pentium III system, but I use the ATA 100
drives instead which are about 50 times faster than the 50 pin
SCSI drives.

In that regard, Ersatz-11 can be considered the "hardware"
and it does log the instructions addresses with only a negligible
overhead.

As for capturing the PC only through a jump, it would probably
take too much overhead to figure out.  The alternative is actually
available under Ersatz-11 which provides direct access to the
memory on the Pentium III via a very small DLL.  I have been
able to request up to half a GigaByte which could be used to
store as many instruction addresses as could possibly be useful.

THANK  YOU for the suggestion.  Maybe my next project will
be an analysis of the instructions which are executed most
frequently.

Jerome Fine

> >On 8/26/2013 9:15 PM, Jerome H. Fine wrote:
>
>> I know of only one example of a debugger which supports
>> a Program Counter History Log.
>>
>> I am in the process of adding a Program Counter History Log
>> to the System Debugger in RT-11 on a PDP-11.  I would
>> appreciate a few suggestions from anyone who has any
>> experience with a debugger program which supports
>> Program Counter History Logging.
>>
>> For users who are not familiar with PDP-11 hardware,
>> the primary interface is a serial terminal, usually with
>> 9600 baud these days (don't laugh - I first started on
>> a PDP-11 around 1975 over a 300 baud modem), with
>> a screen of 24 lines by 80 columns.  There are a probably
>> a VERY, VERY few systems which use VT420 terminals
>> which can support 48 lines, but which are probably rarely,
>> if ever used with other than 24 lines by 80 columns.  From
>> my point of view, the primary considerations are the lack
>> of both speed (9600 baud takes seconds to fill a full screen)
>> and available screen space to display more than about 200
>> addresses from the History Log Buffer (at 10 addresses
>> per line).  While I normally use the Ersatz-11 Emulator for
>> the PDP-11 which provides me the possibility of using
>> screens of 50 lines, I suspect that I am presently the ONLY
>> person to interact with RT-11 using a screen of this many
>> lines, let alone the speed of the screen which is so fast that
>> the time between SCROLL and NOSCROLL is usually
>> a dozen lines of output to the screen.  At 9600 baud, the
>> SCROLL vs NOSCROLL time delay is only a few
>> dozen characters at most, certainly less than one line
>> of output to the screen in almost all cases.
>>
>> The only experience I have with a debugger which has a
>> History Log is with a 64 word buffer of addresses for
>> the 64 immediately previous instructions.  While this is
>> often sufficient to at least pinpoint the general location of
>> where the program stopped, it was often insufficient to
>> locate where the problem started.
>>
>> For those who have direct PDP-11 experience, the
>> following information might also be useful.  At present,
>> there are two buffers which can be displayed:
>>
>> (a)  A buffer with 40 of the last interrupt entries to SD:
>>       which are composed of 5 words each:
>>      -  Program Counter Address from the Stack
>>      -  Program Status Word from the Stack
>>      -  Word (instruction?) at that Address
>>      -  Word (instruction?) at the Previous Address
>>      -  Control Word which is used by SD: (PROSNG)
>>
>> (b)  A buffer with the last 1000 Addresses of the last
>>        1000 instructions that have been executed
>>
>> The current logic in the code to save each instruction
>> address in the 1000 word buffer ONCE and ONLY
>> once uses all five of the above values.
>>
>> There seems no point in displaying all 1000 addresses
>> since only about 200 can stay on the screen and it takes
>> too long in any case.  However, just how useful are the
>> past 1000 addresses as an aid in debugging?  Since it
>> takes no additional time for a larger circular buffer over
>> a smaller circular buffer (in fact maybe a larger buffer
>> is insignificantly faster) and there is memory available,
>> I opted for the largest buffer that was reasonable
>>
>> The other buffer with the 5 word entries entries for
>> the last 40 interrupts will be used when there are any
>> questions about the exact details of any interrupt with
>> respect to a user having set a Breakpoint or any other
>> logic errors in the debugger in general and specifically
>> when adding addresses to the 1000 word history log.
>>
>> NOW finally, here are my questions.
>>
>> Are there any suggestions as to how many previous
>> instructions are needed to usually be helpful to have a
>> log for when a program has a problem?  Also, would
>> it be useful to have the first word (two bytes) of the
>> instruction as well as the address in order to identify
>> the actual instruction or is the address almost always
>> sufficient?  On the PDP-11 with instructions being
>> 1, 2 or 3 words, it is totally unlikely that having the
>> addresses of the previous instructions would ever
>> allow a user to confuse which code was previously
>> executed unless two variants of almost identical code
>> had been purposely constructed so as to confuse the
>> user.  This could occur when two overlays use the
>> same addresses to execute that code, but it is almost
>> impossible to happen by chance and even it it did,
>> an extra NOP could simply shift the code for one
>> of the variants so as to avoid the confusion.
>
[prev in list] [next in list] [prev in thread] [next in thread]