I was thinking of that as well. The question is if conditional branch instructions should also be included as opposed to an actual jump. With regard to conditional branches, the choice could be to stop only if the branch is taken. Note that calling and returning from a subroutine, while not explicitly handled, is managed by controlling the number of words added to or removed from the stack. Agreed. In the past, most of my debugging tends to center on the newest code which has been added in order to determine if the newest code is correct or not. In most cases, the normal method is to step through one instruction at a time and to then determine if the assumptions made were correct and if the expected result occurs. For these situations, single stepping is the only method that seems to be well suited and with a step count of one, no other conditions are required to stop. However, when there is a undetermined bug, just finding what and where the problem is occurring usually takes 90% of the effort. Under this type of situation, additional stopping conditions should be helpful. The major difficulty is that far too much useless information is gathered in such an approach since it is almost impossible to know in advance what is really necessary. Then, writing the code for that sort of approach is also extremely difficult. So while saving only the program counter addresses is rarely sufficient, at least it will usually help to locate where the problem occurred. That can probably be done quite easily. I will need to check. One of the difficulties I am having with the actual implementation is that almost all of the code and data is in multiple PAR1 areas of memory since I am using the Mapped RT-11 Monitor, RT11XM. Thus far, there are 4 * 8192 Byte PAR1 windows of memory, each of which communicates only via a very limited number of words in Low Memory. The use of PAR1 addresses is standard in RT-11 within a device driver, so that part of the solution is good. In fact,, one of the most important challenges during the enhancement was to reduce the number of words in Low Memory as much as possible. However, as a consequence, the data which is required to determine what needs to be done while the code is executing in one of the PAR1 windows is often in a different PAR1. Unfortunately, the required communication always seems to need a few extra words in the first PAR1 and at this point the first PAR1 is totally full - which makes communication rather difficult. Thus far, a solution has eventually been found. Jerome Fine

Using all these features as part of specialized macros. Sometimes I like just the disassembly of the line while single stepping. Sometimes I like just the registers. Sometimes I like both and a small memory window. Being able to combine things is useful, into a single keyboard character. Of course, being able to patch in code, quickly written is another. I use "stop when this expression evaluates true" type of action all the time in my simulators that I write. I do things in Forth so there is always an interpreter there to add what ever is needed. I prefer to use simulators, now that PCs run so fast. Dwight ________________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Mouse <mouse at Rodents-Montreal.ORG> Sent: Monday, February 22, 2016 6:26 AM To: cctalk at classiccmp.org Subject: Re: Helpful Features in a Debugger These and many of the other stop conditions could possibly be subsumed by a "stop when this expression evaluates true" facility, with expression primitives capable of representing all the things you might want to watch. It would of course be CPU-intensive if the expression is complicated, but that's unavoidable, and I have occasionally wished for "run until this number is greater than that number plus twice this register" or the like, even if it runs multiple orders of magnitude slower. (Not when running under RT-11, but that's mostly because I have done little-to-no work under RT-11 at all.) I don't know how common self-modifying code is, but it might be nice to be able to save not just the PC values but the actual instructions executed. (I would hope deliberate self-modifying code is rare, but IIRC some -11s don't have the MMU hardware to prevent accidental self-modifying code - or execution out of areas not normally thought of as instructions.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B