When creating new features for the compiler or the P-Code translator, there are often situations when one of the two passes crashes during execution.
The compiler modules cannot be translated using the debug switch (D+), because they deliberately access arrays outside of the defined bounds in some cases etc., and this is not allowed for D+ modules.
So there was no chance up until now to get readable dumps from PASSNAP, when one of the compiler passes crashes.
I wanted to change this, so I did the following extensions to the P-Code translator:
the true Pascal procedure name was moved to the CSECT identification at the beginning of the CSECT, so that even in the NODEBUG case PASSNAP is now able to show the true Pascal procedure name (this was not possible before; PASSNAP showed the artificial 8 byte CSECT name)
the STATIC CSECT which contains constants and static variables was changed, so that it contains its own length at offset 8; the data itself starts now at offset 16. This way, PASSNAP can produce a hex format dump of the STATIC CSECT (if there is a STATIC CSECT associated with the current procedure block)
the CSECT header was extended, so that it now contains the required stack size for the procedure at position EPA + branch target minus 10. This way, PASSNAP can produre a hex format dump of the current stack segment, when it walks backwards through the call stack.
Of course, all the relevant compiler passes and library modules have been recompiled, and PASSNAP was adjusted to the new module layout.
BTW: the following library modules are considered part of the "standard" Pascal runtime and should be used together with every Pascal program, although not every module will be needed in every single case:
PASMONN - the Pascal Monitor, written in ASSEMBLER (mandatory)
PASLIBX - Pascal Library, contains certain standard functions, which are not implemented by CSPs; only needed, if your program uses one of these functions, or if you use PASSNAP
PASSTRX - Pascal String Library, contains certain standard functions, which are not implemented by CSPs; only needed, if your program uses one of these functions, or if you use PASSNAP
PASSNAP - Library for SNAPSHOT functions; only needed, if you use PASSNAP$ or if you want readable Snapshots in case of a runtime error.
To get good diagnose information in case of a runtime error in one of the compiler passes, I changed the PASRUNC EXEC (which runs the compiler) so that it calls the compiler passes using the following LOAD statement:
LOAD &1 PASMONN PASSNAP PASLIBX PASSTRX (ORIGIN 20580 RESET $PASENT CLEAR
The following file shows a PASSNAP output in the NODEBUG case. The Fibonacci program was changed to NODEBUG; in this case, a subrange domain error would not occur, so I inserted a check for the variable being positive, and if not, I wrote an explicit snapshot using $PASSNAP.
New Snapshot output in the NODEBUG case
If you look at the stack segment outputs, you will see that every stack segment starts with the 72 byte system save area; you can see the backward pointer at offset 4, the forward pointer at offset 8, RET address and EPA address at 12 and 16 and then the registers 0 to 12, starting from offset 20.
You can locate Pascal variables in the hex format dump of the STATIC CSECTs and stack segments by using the offsets printed in the compiler listing. The starting addresses of the areas are printed in the hex dump, too; but it is also the address where the hex dump starts printing hex digits. You only need to add the offset of the variable to the starting address of the relevant area.