SCP Extensions Fixes ==================== INCORPORATED FIXES ------------------ The following modifications to the SCP Extensions module have been incorporated into the global code base and released to the public: 1. PROBLEM: Breakpoint actions after an included true IF are discarded. VERSION: Releases 29 and 8. OBSERVATION: If a breakpoint has actions that include an IF command followed by additional actions, and the IF command evaluates to TRUE, then the IF actions executed, but the remaining breakpoint actions are discarded. For example: sim> set environment X=0 sim> break 10 ; if "%X%" == "0" echo X is 0 ; echo Done sim> go One would expect to see: Breakpoint, P: 00010 (NOP) sim> if "0" == "0" echo X is 0 sim> echo X is 0 X is 0 sim> echo Done Done sim> Instead, only the first ECHO is performed. The second one is discarded. However, execution is correct if the IF condition is false: sim> set environment X=1 sim> break 10 ; if "%X%" == "0" echo X is 0 ; echo Done sim> go Breakpoint, P: 00010 (NOP) sim> if "1" == "0" echo X is 0 sim> echo Done Done sim> CAUSE: IF actions are executed by setting the breakpoint action pointer to the action list and returning to the command loop. While the IF command is executing, the pointer is pointing at the "echo Done" part of the breakpoint action list. However, if the IF condition is true, the pointer is changed to point at the "echo X is 0" command, and the remaining breakpoint actions are lost. RESOLUTION: Modify "if_cmd" (sim_extension.c) to append the remaining breakpoint actions to the actions specified by the IF command, so that the former are not lost. STATUS: Fixed in Releases 30 and 9. 2. PROBLEM: Linking with recent compilers results in duplicate symbol errors. VERSION: Releases 29 and 8. OBSERVATION: If the simulator is compiled with a recent compiler version, the link step fails with duplicate symbol errors. The symbols reported are "sim_vm_release", "vm_sim_vm_init", "vm_console_input_unit", and "vm_console_output_unit". CAUSE: The VM hook extension mechanism is implemented with "tentative definitions" of the hook variables. The C standard says: "If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0." This behavior is such that if no module contains a definition with an initializer, the hook will have a zero value. However, if a module contains a definition with an initializer, the hook is assigned that value. This allows hooks to be set without changing the hook's tentative definition simply by including a VM module that declares it with an initializer. This mechanism relies on the linker to resolve the multiple definitions of a given hook to a single reference. For this to occur, the compiler must mark tentative definitions as "common" allocations, e.g., with the "-fcommon" option to gcc. Traditionally, gcc (and clang, etc.) defaults to common allocations for tentative definitions. However, the gcc manual claims that, "This behavior is not required by ISO C, and on some targets may carry a speed or code size penalty on variable references." Newer versions (starting with gcc 10) default to data allocations instead ("-fno-common"), and multiple tentative definitions now result in duplicate symbol errors rather than merged accesses. RESOLUTION: Modify sim_extension.h to declare "vm_sim_vm_init" only if the USE_VM_INIT symbol is defined. Modify "ex_initialize" (sim_extension.c) to remove the tentative definition and to make the external "vm_sim_vm_init" call conditional on USE_VM_INIT. Modify "one_time_init" (hp2100_sys.c and hp3000_sys.c) to set the "sim_vm_release" hook directly. Modify "tty_reset" (hp2100_tty.c) and "atcd_reset" (hp3000_atc.c) to set the console unit hooks directly. This removes all tentative definitions from the simulators. STATUS: Fixed in Releases 30 and 9. 3. PROBLEM: IF with some pathname arguments can produce erroneous results. VERSION: Releases 30 and 9. OBSERVATION: The IF EXIST command can be used to test for the existence of a filename. However, if the filename contains a Windows path, the command can fail with an "Invalid argument" error without ever testing the file. For example: sim> if not exist "..\HP\2100\data" echo File does not exist! Invalid argument sim> A simple comparison can also fail with an error. For example, assuming that the first substitution argument is "..\2100": sim> if "%1" == "" echo Path name is missing. Invalid argument The existence test can also produce erroneous results: sim> attach -n lpt .\newfile.txt sim> if not exist ".\newfile.txt" echo File does not exist! File does not exist! sim> CAUSE: The IF command takes quoted strings as arguments. Quoted strings are processed for escapes that start with backslash characters. Windows paths contain subdirectory names separated by backslashes. If the first character or characters of the next subdirectory or filename forms a valid escape, the escaped value will be substituted before the file existence test, resulting in a failing test. If the characters form an invalid octal escape, i..e, resulting in a value > 177 octal, an "Invalid argument" error occurs. RESOLUTION: Modify "parse_quoted_string" (sim_extension.c) to accept an "escape" argument that indicates whether escape substitution is to be performed on the quoted string. Modify "ex_break_cmd" and "ex_reply_cmd" to pass TRUE for the escape argument. Modify "ex_if_cmd" to pass TRUE if the new "-E" switch was present or FALSE if it was not. STATUS: Fixed in Releases 31 and 10. 4. PROBLEM: Concurrent DO following RUN/GO jumps to on resumption. VERSION: Releases 30 and 9. OBSERVATION: A DO command may be entered in concurrent mode to execute a series of commands stored in a file. When the command is entered, execution is suspended while each command in the file is performed and then resumed when the command file is exhausted. However, if execution was started with a RUN or GO command that specified a new program counter value, execution will resume at that location rather than at the location where suspension occurred. An example illustrates the problem: HP 2100 simulator V3.11-2 Release 30 sim> deposit 0 JMP 100 sim> deposit 1-7 NOP sim> deposit 10 JMP 0 sim> deposit P 0 sim> step Step expired, P: 00010 (JMP 0) sim> step Step expired, P: 00000 (JMP 10) sim> step Step expired, P: 00010 (JMP 0) sim> step Step expired, P: 00000 (JMP 10) sim> As can be seen, the two program instructions jump between locations 0 and 10. Starting execution with: sim> go 3 ...causes the simulator to execute the no-operation instructions at locations 3 through 7, and then jump between locations 10 and 0 repeatedly. Now, given a command file "halt.sim" that contains: deposit 5 HLT 0 set console debug=stdout set cpu debug=instr ...then issuing a DO command to perform the deposit should not affect simulator execution, because the halt instruction is bypassed by the jumps, and the instruction trace should show only the repeated jumps. However: scp> do halt.sim Debug output to "STDOUT" >>CPU instr: - 0000 00003 000000 NOP >>CPU instr: - 0000 00004 000000 NOP >>CPU instr: - 0000 00005 102000 HLT 0 >>CPU instr: - 0000 00005 102000 simulation stop: Programmed halt Programmed halt, T: 102000 (HLT 0), P: 00006 (NOP) sim> CAUSE: After stopping execution to perform the DO command, the run handler routine is reentered with the original command ("GO 3") rather than simply continuing. In this case, the program counter is reset before execution continues. Moreover, if the original command was RUN, all devices would be reset before execution continued, destroying the existing device state. RESOLUTION: Modify "ex_run_cmd" (sim_extension.c) to change the command to CONTINUE before execution is resumed following a concurrent DO. STATUS: Fixed in Releases 31 and 10. 5. PROBLEM: Attempting to use a Windows virtual serial port fails. VERSION: Releases 31 and 10. OBSERVATION: In the Windows Bluetooth settings, one virtual serial port can be defined per Bluetooth connection. The Windows device manager can be used to change the virtual port's baud rate, word length, parity, stop bits and flow control. However, attempting to use the virtual serial port fails. For example: sim> attach BACI COM1 File open error sim> The same command works if COM1 is a real serial port. Stepping through with the debugger shows that the "GetDefaultCommConfig" call at the start of the "sim_open_serial" routine is failing with I/O error 87, which is ERROR_INVALID_PARAMETER. CAUSE: "GetDefaultCommConfig" is called to obtain the default serial port settings. These are used for an ATTACH command that does not specify an explicit configuration string. It is not clear why the routine fails with a virtual port while succeeding with a real one. However, initializing a port to the default configuration is a convenience, not a necessity. If the routine is bypassed, the ATTACH succeeds. RESOLUTION: Modify "sim_open_serial" (sim_serial.c) to move the call to "GetDefaultCommConfig" to the "sim_config_serial" routine, where it is called only if the user did not specify an explicit configuration string. Modify the latter routine to return SCPE_2FARG ("Too few arguments") if the "GetDefaultCommConfig" call fails, so that the user knows to reenter the ATTACH command with an explicit configuration. STATUS: Fixed in Releases 32 and 11. xxx. PROBLEM: A breakpoint stop after a command file completes is not displayed. VERSION: Releases 31 and 10. OBSERVATION: If the last command in a command file starts execution, then if the simulator stops for a breakpoint, the stop message is not printed. The user then has no idea why simulated execution has ceased. CAUSE: RESOLUTION: Modified "execute_file" (sim_extension.c) to... STATUS: Fixed in Releases 32 and 11. ——————————————————————————————————————————————————————————————————————————————— xxx. PROBLEM: VERSION: Releases . OBSERVATION: CAUSE: RESOLUTION: STATUS: Fixed in Releases .