- Limit choices to explicitly either G-FLOAT or D-FLOAT for SET CPU INST=
- Compile in all instruction implementations and dynamically use the
enabled ones.
- Different VAX models had different groups of instructions which were
implemented in hardware vs trappng to the OS for emulation. Functionality
has been added to differentiate the various mix of instruction groups for
different models and to display both the groups and the actual instructions.
- Visibility to Instruction groups is provided by SHOW CPU INSTRUCTIONS
and the list of the active instructions implemented and emulated via
SHOW CPU -V INSTRUCTIONS.
- The MicroVAX I CPU handled some execution fault conditions differently
from other VAX systems these differences are now specifically handled.
- Add build time test support to MicroVAX I running EHKAA v1.13
suggested in #683
- Add more CPU debug details relating to exception and interrupt processing
Originally, the VAX allowed immediate operands (8F) to be used without
restrictions in address mode instructions, either standalone or indexed.
Starting with MicroVAX II, immediate indexed became reserved. This
remained true for all subsequent chip implementations. The SRM was
ECOed in March, 1985 to make immediate indexed unpredictable.
In MicroVAX II, immediate g-floating operands didn't work correctly. The
problem was found a couple of months after tape-out. While the index
flows could be fixed, and were fixed according to the microcode revision
history:
; 7-May-84 [RMS] Fixed FD problem in index flows (JLR)
the problem in indexed immediate could only be fixed by a significant
hardware change in an area that was already packed full. The VAX
Architecture Team, which had always been very sympathetic to the
VAX chip efforts, proposed a much simpler solution: make immediate
indexed unpredictable. It was useless, in any case.
I'm rather surprised that this wasn't flagged by the 780 diagnostics.
Maybe it was never tested. It was tested in HCORE (the original MicroVAX I
core diagnostic that is failing), but I removed it subsequently:
; 8-may-85 rms removed indexed immediate tests
Bottom line - the simulator is right for the chip VAXes (including, I think,
V11) and wrong for MicroVAX I and probably the 8600, 780, 750, and 730.
# Conflicts:
# VAX/vax_cpu.c
Many of the intermediate state variables are captured by the instruction
history mechanism. Make sure that these don't come into and out of
scope between instruction executions.
Previously sim_interval was adjusted by 1 plus the total number of bytes
referenced in string instructions (SCANC, SPANC, LOCC, SKPC, CMPC3,
CMPC5, MOVC3, MOVC5). Since the amount of data that a string
instruction can reference is arbitrarily large (32bit size), the adjustment
to sim_interval could be ridiculously excessive. This can result in wild
variances in clock calibration when large string data are referenced.
The original idling model called sim_idle() within the context of a scheduled
event running on the CPU unit. The overhead of scheduling and the related
dispatch serve no specific purpose.
Meanwhile, the 'work' involved in determing if idling is possible is about
equivalent to the work of executing an additional instruction. Therefore
sim_idle is invoked with an argument which causes the sim_interval to be
adjusted by 1 on each call that doesn't actually perform an idle sleep. This
adjustment keeps the calibrated instruction execution rate consistent with
other purely non-idle instruction mixes.
Asynchronous clocks are now built for all simulators which are built with
SIM_ASYNCH_IO defined. The default behavior has asynchronous clocks
disabled since this is still experimental, but it can be enabled with
SET TIMER ASYNC.
Catchup clock ticks are now available, but since they're experimental,
they aren't enabled by default. Catchup ticks are only available if the
simulators clock device calls sim_rtcn_tick_ack to acknowledge processing
of clock ticks. The VAX simulators have been modified to leverage this.
Catchup clock ticks can be enabled with SET TIMER CATCHUP
Additionally, an idle threshold is provided which can be used to
influence when clock calibration may be suppressed. The default is not
to suppress calibration activities.
The various timer behaviors are visible with the SHOW TIMER command.
The state of the operating timer facilities is visible with: SHOW CLOCK
Timer events which are queued are visible with the SHOW QUEUE command.
Recent enhancements to idle/infinite loop detection generalized handling
of detecting 'loop to self' cases. This was done without considering that
some instructions have side effects (i.e. change other state like the stack
pointer) and thus aren't merely loop to self cases.
This problem was reported in #315
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.
A user could change the contents of the PSL via a DEPOSIT command.
If the resulting PSL indicates Interrupt Stack and IPL is 0, then this is
equivalent to MTPR #0,#IPL which is explicitly described as "undefined"
When a MTPR #0,#IPL is performed, the VAX chip microcode doesn't check,
neither does the 780 microcode. Nothing bad will happen immediately,
however when an interrupt occurs, the saved PSL will now contain IPL 0
and Interrupt Stack. This combination will cause the REI dismissing the
taken interrupt to fail. To avoid a user manually creating this via
a DEPOSIT command or to potentially detect this condition while stepping
through instructions this check refuses to execute when the PSL is
invalid. This change merely provides an explanation.
On page 5-37 of the VAX SRM (DEC standard 32), the REI pseudo-code defines
exactly what a legal PSL looks like. The check at the beginning of
sim_instr is a direct implementation of that check, intended to prevent
the user from creating an inconsistent PSL through the simulator console.
In a VAX chip, the console code would exit by a genuine REI, and any
illegal value created by the user would cause a system stop (return to the
console).
On page 5-43, the revision history notes that in rev 8 of chapter 5,
MTPR #0,#IPL was made undefined. Because MXPR is privileged, and the
general assumption was that VMS knew what it was doing, no one realized
the potential inconsistency that MTPR #IPL could create until it was
too late. "Undefined" allows any behavior, up to and including blowing up
the system.
This is invoked with STEP -R nnn, or CONT -R. Execution will continue
across any new subroutines which are called and stop after the current
routine executes a RET or RSB instruction.
SET CPU IDLE={OS{:n}} where n is the idle stability delay
which is also the clock calibration delay.
A -D switch on a SHOW -D CPU IDLE command will
display the stability delay as will a SHOW CLOCK command.
simulator time allows instruction history to be precisely correlated with
debug output. It also provides a way to reproduce and review simulation
activities by stopping at predetermined time values (via STEP) to
examine details of simulator state.
disk logging can be useful to compare activities performed in separate
simulator runs.
The MicroVAX II boot ROM has code uses one of these instructions with the
data being referenced somewhere in Qbus space. This is not supposed to be
done according to the architecture specifications, but it must have worked on
real hardware. In any case, as a consequence of this reference to I/O space,
these otherwise non-data modifying instructions can have side effects or
reference data which may change even in an instruction looping on itself.
Given that potential, such use isn't an infinite loop which would otherwise
inspire a drop back to scp.
This allows pending I/O (console, or otherwise) to complete before dropping
back to the sim> prompt. This better simulates the model where scp is analogous
to the console processor on the older VAX simulators. This better addresses the
incomplete I/O problems discussed in #208
Prior logic attempted to load the desired file from the current default directory and if that failed wrote the in memory boot code image to the desired file and then retried the desired load..
A user can still explicitly load a ROM image with a "LOAD -R romfile.bin" command prior to a BOOT attempt if they want to test or otherwise run with a different ROM.
