When SimH was written, its design assumption was a 32b host simulating
smaller than 32b targets. As a result, all the early simulators play
fast and loose with signed vs unsigned integers, because the data was
always 6b or 8b or 12b or 16b or 24b in a 32b container. Even if the
container was signed, overflow wasn't possible, provided that operands
were always the simulated word length. So all the pre-2000 simulators
use int32 for almost everything. Only where it really mattered
(typically floating point units, which have 32b or 64b data) was use of
unsigned carefully observed.
The PDP10 led to support of 64b hosting environments, but it did not
violate the assumption that simulated data was always a positive integer
in a larger container (36b in 64b, in this case).
After 2000, and some bad experiences with the first C99 compliant
compilers, the simulators I wrote used unsigned integers for almost
everything. This can be seen in the Interdata, 7094, GRI, LGP, Sigma,
Alpha, and MIPS simulators. But I didn't retrofit any of the old
simulators, because I didn't want to redo an enormous amount of
validation work (including, recently, testing against every compiler
known to the community). With one exception, it's not important.
The anomaly is the VAX. The VAX makes two critical assumptions. The
first is that a (u)int32 is EXACTLY 32b, a (u)int16 EXACTLY 16b, etc.
This means that the VAX code omits an enormous amount of masking,
particularly with LMASK (0xFFFFFFFF). The second is that arithmetic on
signed integers works like x86 2's complement arithmetic - no overflow
traps, no strange wrapping. In short, the VAX is a pre-2000 simulator.
If there are problems in the VAX with modern compilers, I would look
more to signed/unsigned or variable promotion than pointer aliasing. The
simulators (as opposed to SCP) don't use pointers very often, because
registers and memory are treated as arrays. But if a compiler promotes a
(signed) 32b variable to 64b and assumes that 64b operations will work
from then on, it could lead to all kinds of disasters.
/Bob
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
