At 12:00 -0500 8/27/13, Jerome Fine wrote:
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?
Jerome,
hopefully you'll get much better-qualified answers than mine;
I have little to no experience programming assembly or PDP-11. That
said, I can think of a few possible answers:
1) enough instructions that any timing-critical loop will be captured
when an external interrupt dropping into the debugger is generated.
This might be relatively short - 200 instructions or so? User
(not necessarily programmer?) would set up and start a long
calculation (mandelbrot set, whatever) and then hit "break", and be
able to look back far enough to verify that the correct sequence of
instructions is repeating over and over.
For actual number, maybe look at the longest loop in RT-11
that repeats many times successively?
2) enough instructions that any timing-critical *subroutine" will be
captured when dropping into the debugger.
This would be a *lot* more, depending on application. In this
case, the programmer would add a break point to the code right after
the timing-critical routine (disk access, real-time control interrupt
service routine, whatever) and then look back at the buffer to verify
that the whole routine took the correct execution path. For disk
access, that might be a *lot* of loops, though, so maybe you are only
capable of writing a buffer to hold the last few iterations?
For actual number, look at the longest single executable code
unit in RT-11?
3) Configurable depth, configured at launch time for debugger
Programmer gets to make the trade between debugger buffer
depth and available memory for his program.
Not sure any of this is helpful, and you probably have
thought of it anyway.
--
- Mark 210-379-4635
-----------------------------------------------------------------------
Large Asteroids headed toward planets
inhabited by beings that don't have
technology adequate to stop them:
Think of it as Evolution in Fast-Forward.