From page 6-6 of DEC STD 032 (the VAX architecture spec):
"Execution of MTPR src, #PR$_ASTLVL with src<31:0> GEQU 5 results in
UNDEFINED behavior. The preferred implementation is to cause a reserved
operand fault." MicroVAX II, CVAX, and Rigel all conform to the preferred
behavior, as does the current simulator, which was written from the CVAX
microcode. NVAX masks to 3b and does not take an exception on a value
GEQU 5.
The 1982 Architecture Handbook describes ASTLVL as a 3b register, with
src<31:3> ignored/read as zero, and exceptions taken on values GEQU 5.
The780 microcode masks the input value to 3b before doing the GEQU 5 test.
The ASTLVL test needs to be model specific.
I suspect the behavior became undefined when MicroVAX II simplified the
original test to save a microword. I do not see how the code fragment Matt
references could work on a MicroVAX II, which was supported under 4.5.
Perhaps the device Matt mentions couldn't exist on a MicroVAX II?
For those who wants the gory details... uVAX, CVAX, and Rigel do an
unsigned compare on the unmasked src and the constant 5. Carry out
means reserved operand. Overflow is ignored. So an input of 0x80000002 -
0x00000005 (done in the data path as 0x80000002 + 0xFFFFFFFB) generates overflow (ignored) and carry out.
# Conflicts:
# VAX/vaxmod_defs.h
Cleaned up a couple of things here. Specifically:
1) scp_reading is only set when CmdThread is actually reading.
2) Avoid calling ResetEvent(hCmdReadEvent) since it has no effect.
3) Calling ReadFile directly rather than calling read_line which ultimately
calls fgets(stdin) and that ultimately calls ReadFile.
4) Added a cleanup mechanism to shutdown the CmdThread
and related open handles to Events and Thread when the program exits.
Remaining potential problems:
1) A user might have type a partial command (scp_reading) but not
completed it by hitting Enter, and then they perform some GUI
interaction which does other things. Some strange output will be
produced on top of the partially entered command line.
2) Whether or not a complete command has been entered, the original
CmdThread will have a read posted on stdin throughout any activity
initiated by GUI activities. It is not clear that the simulator’s console
will coherently be able to change the console’s mode from the line
oriented mode that SCP uses to the character oriented mode used
while instructions are executing with read pending on the input side.
Modified the UBA750 simulation, incorporating these comments. Ultrix
appears to access the non-existant datapath registers and given that this
works on the real hardware the most likely option seems to be read 0
and write NOP. I think this will be true for any access to the UBI outside
of the known registers.
