vax8600 diagnostic failure

[LegalizeAdulthood]

When I build using Visual Studio x64 2026 using vcpkg and run the tests, I get this failure:

1/1 Test #68: simh-vax8600 .....................***Failed    1.31 sec
 Running internal register sanity checks on VAX 8600 simulator.
*** Good Registers in VAX 8600 simulator.

VAX 8600 simulator Open SIMH V4.1-0 Current        git commit id: 24351887+uncommitted-changes
Running Hardware Core Test (EVKAA)

                VAX DIAGNOSTIC SOFTWARE
                        PROPERTY OF
              DIGITAL EQUIPMENT CORPORATION

            ***CONFIDENTIAL AND PROPRIETARY***


Use Authorized Only Pursuant to a Valid Right-to-Use License


EVKAA V8.0 Hardcore Instruction Test

Hit any key to continue
EVKAA V8.0 pass # 1(X) done!
??? ERROR - Test # 13, Subtest # 04, Free run failed
ICR is incorrect
Expected - 00000001
Received - 00000001
*** FAILED - VAX 8600 Hardware Core Instruction test EVKAA



0% tests passed, 1 tests failed out of 1

Label Time Summary:
simh-VAX    =   1.31 sec*proc (1 test)

Total Test time (real) =   1.32 sec

The following tests FAILED:
         68 - simh-vax8600 (Failed)                             simh-VAX
Errors while running CTest

Previously I'd gotten some other failures on vax, but re-running the tests cleared them. When they fail, they fail with the same output:

ICR is incorrect
Expected - 00000001
Received - 00000001

I suspect this is some sort of 64-bit vs. 32-bit confusion in the code because you can see that the diagnostic says "expecting 1, got 1" and there are many warnings about conversions when building the code for 64-bit.

[LegalizeAdulthood]

I was running the tests in parallel, don't know if the tests themselves use the filesystem and are possibly stomping on each other's files.

If I run the tests one at a time, I still get failures, so I don't think that is the cause.

[LegalizeAdulthood]

I see similar results when building on linux.

[markpizz]

The makefile build on Linux has no such problem with the build results. The tests for the VAX8600 simulator run to completion without issue.

$ make vax8600

Similarly, the legacy build on Windows also has no such problem. The tests for the VAX8600 simulator run to completion without issue.

build_vstudio.bat vax8600

[LegalizeAdulthood]

Then build it with CMake

[markpizz]

If it works with the legacy build mechanisms on BOTH Linux and Windows, but fails with CMake builds (on both platforms), then the problem just might have something to do with what is going on with the CMake activities.

[pmetzger]

@LegalizeAdulthood The Vax simulator has lots of problems with undefined behavior. Make sure that the compiler flags are set to define signed integer overflow. This is done on other platforms already, it might be broken on Windows.

[markpizz]

You are on the right track. The report specifically mentions cmake builds having this problem on BOTH Windows AND Linux.

The problem DOES NOT happen with the makefile build on Linux OR the Visual Studio project build on Windows.

Someone should fix the cmake build.

[LegalizeAdulthood]

Like I said, try building it with CMake AND a modern compiler.

[McNeight]

Someone should fix the cmake build.

Someone started to seven months ago, and his pull request has sat ignored for that entire time.

#497

[pkoning2]

Ouch. I know I'm behind, but that's much worse than I thought. I'll work on that. paul

…

On Apr 12, 2026, at 5:51 PM, Neil McNeight ***@***.***> wrote: McNeight left a comment (open-simh/simh#533) <#533 (comment)> Someone should fix the cmake build. Someone started to seven months ago, and his pull request has sat ignored for that entire time. #497 <#497> — Reply to this email directly, view it on GitHub <#533 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACL6J763STZ3Q2K6HG4U7QL4VQFVXAVCNFSM6AAAAACXUEVJTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZSHAYTONBZG4>. You are receiving this because you are subscribed to this thread.

[LegalizeAdulthood]

I'm pretty sure the problem is not the CMake build itself, particularly considering all the warnings that are emitted on both linux and Windows.

For what it's worth when I build explicitly with vs2022, I didn't reproduce the problem, although the failures are flip-floppy. This points the finger at "working by accident" code that fails to work correctly with newer, more stricter compilers.

@pkoning2 If you're on discord, please use this link and we can chat directly about it: https://discord.gg/PGkXUD7y

[markpizz]

@LegalizeAdulthood said: Like I said, try building it with CMake AND a modern compiler.

CMake is using precisely the same compilers on Windows as well as on Linux as the makefile and the way it is currently configured to invoke those compilers them produces:

1. At least one simulator that fails it's functional tests as you pointed out when opening this issue
2. The many warnings on both Linux and Windows that you mention.

Meanwhile, the makefile and the legacy Windows Visual Studio build mechanisms (again using the exact same compilers):

1. produces functional simulators that pass their tests.
2. produces no warnings while building simulators

Where should the blame be for these problems that only occur with the CMake build?

I believe that it is NOT in CMake itself, but in how the compilers are configured when used by CMake. It would seem to be possible for someone very interested in using the CMake build mechanisms to actually fix things.

[pmetzger]

For what it's worth, although I will continue to contribute to SIMH into the future, I'm also working currently on a fork that completely renovates the codebase. I think it's difficult, given the velocity things are currently operating at, to make the improvements necessary to keep the code working for decades and centuries to come.

[LegalizeAdulthood]

@pmetzger Unfortunately Bob Supnik works on improvements outside of github and doesn't pull changes from here into his working code. So renovating the code unfortunately makes it harder to incorporate improvements from Bob.

[markpizz]

I said: "Meanwhile, the makefile and the legacy Windows Visual Studio build mechanisms (again using the exact same compilers):"

What I mean when I say Legacy is the mechanisms in the repo that were there BEFORE the introduction of CMake. The makefile is one of those Legacy mechanisms for *nix systems. The "Visual Studio Projects" are the Windows Legacy mechanisms along with the build_vstudio.bat file at the top of the directory. The CMake and CI builds were written to solve the build process in a different way. Nothing in the primary CI activities that happens to have a name which includes the word "LEGACY" in it's name is absolutely not what I was referring to.

Additionally, @LegalizeAdulthood said: "Unfortunately Bob Supnik works on improvements outside of github and doesn't pull changes from here into his working code. So renovating the code unfortunately makes it harder to incorporate improvements from Bob."

The VAX simulator codebase in the open-simh/simh and simh/simh repos have been very stable for a very long time (approximately 15 years).