[Simh] SimH and modern C

Bob Supnik bob at supnik.org
Wed Feb 17 18:15:37 EST 2016


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


More information about the Simh mailing list