Previously, the history would always use a register value as source or
destination as if the mode were zero, even when it wasn't. Also, now
the destination value reflects the destination after instruction
execution rather than before.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
The problem has to do with the difference in how the PSW is stored when
the simulator is running (it's all in pieces) or stopped (it's collected in PSW).
cpu_ex is a console routine and expects the PSW to be stored in PSW, but
when history is collected, it's not. In particular, cm (current mode) is in local
variable cm.
cpu_ex with /v calls relocC, which derives the current mode from the
switches:
- if /ksup, use kernel/supervisor/user/previous mode (from PSW); otherwise,
use current mode from PSW
- if /d, use data space; otherwise, use instruction space
relocC is doing current mode i-space, which is what's wanted... except that
it's deriving current mode from PSW, rather than cm, which is where it's stored
while the simulator is running. It's fairly likely that PSW is long obsolete by the
time the history is invoked.
The mapping of addresses in the I/O page needs to be populated before
it can be referenced. This change allows commands at the initial sim>
prompt to touch device registers with EXAMINE and DEPOSIT as discussed
in #261
This capability will allow a GDB RSB stub to be created to support dynamic debugging of code running in a simulator.
This capability will also allow a complete front panel emulation system to operate a simulator.
This capability is engaged in a simulator by:
sim> set remote telnet=remoteconsoleport#
sim> set console telnet=consoleport#
sim> set remote master
Master mode will provide a TCP session which accepts SCP commands that allow full control of the simulator.
John Dundas said:
Bob and all,
I ran across what I believe to be a bug in the CSM code:
case 070: /* CSM */
if (CPUT (HAS_CSM) && (MMR3 & MMR3_CSM) || (cm != MD_KER)) {
According to the Architecture Handbook, CSM may be executed only if the MMR3 bit is set AND the mode is not Kernel. Changing the code to:
case 070: /* CSM */
if (CPUT (HAS_CSM) && (MMR3 & MMR3_CSM) && (cm != MD_KER)) {
also has the effect of making the ZKDKB0 diagnostic much happier.
Thanks,
John
--
John A. Dundas III
This required a simulator specific implementation since the PDP11 PC register isn't stored in a normal memory location. It is loaded from a temporary location upon simulator instruction execution startup (and saved to that location when instuction execution stops). In order to reference the PC value while executing instructions (for debug output), this extended access model is required.
Here's a PDP11 SIMH bug as old as the simulator itself: the reset_cpu routine sets the PS to 340 (interrupts disabled). This causes some versions of Lunar Lander not to work. In fact, the initial state of the PS is not architecturally standardized:
04: cleared (from schematics)
05: cleared (from manual)
20: cleared (from schematics)
34: cleared (from schematics), set to 340 on boot?
40: cleared (from schematics)
44: cleared on init, set to 340 on boot (from schematics, manual)
45: cleared (from schematics)
60: cleared (from schematics)
70: cleared (from schematics)
T11: set to 340 (from spec)
LSI11, F11: 4 mode behavior (from memory on power recovery, cleared on GO, 340 on boot, mode 3 undefined)
J11: 4 mode behavior (from memory on power recovery, cleared on GO, 340 on boot, 340 on jump to custom PROM)
The story seems to be this. All non-VLSI PDP11s used TTL chips to implement the PS, either discrete flip-flops, or 4b registers, or both.
Starting with the first system, the 11/20, they were wired clear on the processor INIT signal (power-up or front panel START switch), so that all internal state started as 0. This worked fine, because START also reset the Unibus and cleared all interrupt enables. So even though the processor was as IPL = 0, no interrupts were possible. Then along came the LSI11...
The LSI11 implemented a line-time clock with NO INTERRUPT DISABLE. Thus, if IPL was left at 0 and a bootstrap routine from a slow device was started (e.g., a floppy drive), the clock would tick, and an interrupt would occur, before the bootstrap routine finished. Because no vectors were set up, the processor would crash. So the LSI11 started the practice, carried over to all later PDP11 VLSI chips, of setting the PS to 340 before jumping to a boot ROM.
The T11 did this in all modes of startup, because its only startup behavior was to jump to a "boot" routine. It did not have a console of any kind.
Accordingly, it appears that the cpu_reset routine needs to set the PS based on the processor model. Further, all boot routines need to set the PS to 0 or 340 based on the processor model. (It's probably safe for boot routines just to set the PS to 340, but it's not technically
accurate.)
It does not fix the problem that MMR1 is not used for floating point instructions.
I don't know if I will fix the FP MMR1 problem. It does not seem to impact running software. It is consistent with the architecture spec - just not with the actual J11 implementation. The J11 microcode has a variety of exception exits for FP conditions, and I have to trace which ones invoke fix-up, and which do not.
