On Thu, Sep 02, 2010 at 02:00:34PM -0400, Jason Stevens wrote: > some kind of a 'test suite' to really verify that these emulators work > correctly.
My favorite solution over the years as the debian maintainer has been to use expect, bash scripts, wget, and md5sum. So, say someone contacted me directly explaining the ARM debian distribution seems not to be working on pdp8. I use a bash script that automates: wget's some relevant papertape or whatever of diagnostic routine runs a short expect script on simh pdp8 or whatever that executes the diagnostic routine and saves the disk images etc. md5sum the resulting output, and compare to the "golden" correct answer. The Expect language is only 20 years old this year, I think its stable enough to use now... I've always dreamed of having commit access to simh to add something like this for all the diagnostic (paper-)tapes, disks, etc. (And I've always wanted commit access to a /debian directory to maintain the debian related stuff, I'll keep on dreamin..) There is also no reason that the entire contents of http://gunkies.org/wiki/Category:SIMH_Tutorials could not be executed in an expect script. Then its OK as long as the md5sum of the end result matches my golden result. I would advise that a complete test distribution for all simh machines would probably increase the size of simh by several orders of magnitude, so it might be nice to split it up into simh-pdp8-testsuite, simh-pdp10-testsuite, etc. Someone uninterested in PDP-10/TOPS-10 might balk at having to download a full tape set, etc. Going further it might be nice to split the whole thing up into its constituent parts. Someone hacking on the 1401 is probably uncorrelated with the guy patching the LGP-30, so no point making his "git pull" slower. So, my advice, which would probably freak out the sourceforge or whatever admins, would be separate git repositories for simh-core, simh-pdp1, simh-pdp18B, simh-altair ... and simh-pdp1-testsuite, simh-pdp18B-testsuite etc. A nice part of the test suite would be to record the exact time it takes to run each test, to see if modifications have resulted in a surprising change in execution time. For over a decade I've dreamed of a simh with real time execution, so it runs and I/O operates at "real time" speeds, or perhaps a configurable multiple thereof. I've always believed the current idle loop detection system is an architectural and scalability dead end, the solution to a PDP-8 running at 100 times real speed and hogging the host CPU 100% is to force the PDP-8 to run at "configurable real speed" and ignore that its hogging a whopping 1% of the host CPU in the idle loop. _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh