- OS X libpcreposix segfaults when a compiled regular expression is freed.
- Revise regular expression syntax used in VAX diagnostic scripts to avoid
Perl oriented extensions.
- Diagnostic execution happens as a normal part of the makefile build.
- Diagnostic execution can be suppressed by invoking make with TESTS=0
on the command line
- Diagnostic execution during build is produced in summary form.
Previously the CPU model was only being set when the CPU ROM was
implicitly loaded from the internal ROM image at boot time. Other
loading of ROM code never set the configured model correctly.
- Properly set the Interval Register when a running timer is stopped
- Peoperly clear timer interrupt pending when CSR is updated
- Properly handle the case when the timer is started with the interval
register is 0.
- Properly stop the running timer when it is restarted or adjusted
with a new interval value.
- Better debug info
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
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.
Whilst working on a new video device I ran into a few problems with the
LKxxx keyboard and I noticed there are already some open issues against
the keyboard and mouse devices. These changes should resolve#320 and
may help with #272 (although I think that is an SDL issue). I've tested these
changes with VWS, UWS and DECwindows with both captured and
uncaptured input modes.
the opcode table first word consists of bits:
<7> = FPD is legal for this opcode.
<4:6> = number of specifiers for unimplemented opcodes (VAX subsets)
<3> = unused
<0:2> = number of specifiers
The mask used to be 0x70. The convention is that x_M_y is a mask value
<right-justified>, for a macro like:
#define get_foo(x) (((x) >> x_V_foo) & x_M_foo)
For a subset VAX (like the 3900), the unimplemented opcodes are those
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.
IPL_UBA already has the subtract built in:
So it shouldn't be extracted again.
The whole routine looks a little strange, but the way it works is
that an interrupt from the UBA itself sets <bit 31> in the returned vector.
Because the vector is read by code and not used by hardware, the flag
bit is "harmless."
UBA interrupts occur only under strange circumstances, like bad map
pages and device NXMs. Under the simulator, with a debugged OS, they
never happen.
IPL_UBA already has the subtract built in:
So it shouldn't be extracted again.
The whole routine looks a little strange, but the way it works is
that an interrupt from the UBA itself sets <bit 31> in the returned vector.
Because the vector is read by code and not used by hardware, the flag
bit is "harmless."
UBA interrupts occur only under strange circumstances, like bad map
pages and device NXMs. Under the simulator, with a debugged OS, they
never happen.
