[Simh] VAX emulation issues on Raspberry Pi

[Mark Pizzolato]

On Tuesday, July 31, 2018 at 5:48 AM, Timothe Litt wrote:
> On 31-Jul-18 01:31, Jeremy Begg wrote:

> > The license wouldn't be an issue if the SET CPU MODEL command worked.
>
> It looks as though it works - but not as you (or I) expect.  It defines the 
> SimH model - which is mostly I/O devices.
> 
> Your issue is with the SYS_TYPE register, which lives at location 0x40004 in 
> I/O space of MicroVAX systems.
> This is the ROM - SimH just uses what is loaded.  It's included in the ROM checksum.
> 
> SET CPU MODEL should probably update the register, which has the format:
> <31:24>SYS_TYPE <23:16>REV <15:8>SYSDEP <7:0>LicenseID
> SYS_TYPE qualifies the SID - the codes are re-used.

The code in the MicroVAX 3900 simulator that implements the 
SET CPU MODEL=(MicroVAX,VAXServer) command, does indeed update exactly 
this register/ROM location:

    MicroVAX 3900 simulator V4.0-0 Current        git commit id: b18fa8c0
    sim> b
    Loading boot code from internal ka655x.bin

    KA655-B V5.3, VMB 2.7
    Performing normal system tests.
    40..39..38..37..36..35..34..
    Simulation stopped, PC: 20051C04 (MOVL (R1),R0)
    sim> e 20040004
    20040004:       01530302
    sim> sh cpu
    CPU     idle disabled, model=VAXServer 3900 (KA655), NOAUTOBOOT
            16MB, HALT to SIMH
    sim>

    MicroVAX 3900 simulator V4.0-0 Current        git commit id: b18fa8c0
    sim> set cpu model=microvax
    sim> b
    Loading boot code from internal ka655x.bin

    KA655-A V5.3, VMB 2.7
    Performing normal system tests.
    40..39..38..37..36..35..34..33..32..31..
    Simulation stopped, PC: 2004E9CB (CMPL R0,R4)
    sim> e 20040004
    20040004:       01530301
    sim> sh cpu
    CPU     idle disabled, model=MicroVAX 3900 (KA655), NOAUTOBOOT
            16MB, HALT to SIMH
    sim>

The fixup of the ROM/register contents was only being done when the ROM code is initially loaded from the built in ROM image, hence the need to start over to set the model and have an effect.  No fixup was being done if someone explicitly loaded a ROM image from a file (probably what the OP was doing).  There is no good reason not to set this register to the configured type prior to each boot.  I'll make that change later today.  

> I don't have the complete list of SYS_TYPE codes, but a few are:
> UVAX:
> 
> 1 UV2, 4 Uv2000/vs2000, 5 VAXterm, 6 9000 console
> 
> CVAX:
> 
> 1: uvax(35/36/33/34/38/3900), Vaxserver(35/26/33/34/38/3900), Vaxstation(32/3500)
> 2: VAX 62x0, 63x0
> 3: Vaxstation( 3520/40)
> 4: vaxstation 3100
> 7: FT5200
> 
> Rev is 1-based.
> 
> <0> is set for a timesharing system.
> <1> is set for a single user system.
> 
> It would have to recompute the ROM checksum.

The ROM checksum doesn't need to be adjusted since the checksum validation code was disabled long ago when the first 'adjustments' to the ROM's contents were made when the MicroVAX 3900 simulator was initially being done.

VMS's licensing logic sometimes also includes detection of devices present within the machine independent of the ROM or processor supplied register information.  For example, all UV2 boards had equivalent ROMs whether they were present in MicroVAX systems or VAXStation systems.  The presence of a QVSS or QDSS board made the system a VAXStation and thus had different licensing requirements.

> > I recall some of that discussion.  I think the SSH server is having to do a
> > whole lot of math to come up with sufficient entropy and no doubt that's a
> > lot of floating point.
> > It would be odd if it was FP - crypto is generally multi-precision integer.
>
> Entropy doesn't come from math.  It comes from I/O, timers, or these days, 
> from a hardware noise source.
> There is some math involved in whitening - but it's mostly shifts & xors.  Not FP.
> SimH is more predictable than real hardware.
>
> You can probably settle this by enabling CPU history, and randomly pausing 
> emulation and dumping the buffer while you are waiting.

Good suggestion, he should be prepared for a much slower experience.  History 
recording significantly reduces instruction execution rates.

> > It occurred to me that the emulation I'm running is a -3900 series machine
> > which if memory serves, did not have an FPU.  Meaning all those VAX floating
> > point operations are being emulated twice -- once by the VAX and once by
> > SIMH.  Is that correct?  If so I wonder if the emaulation could be tweaked
> > to behave as if the emulated machine has an FPU.
>
>  The only VAX without an FPU was the early 780, which was ECOd.
> There are some emulation options:
>
> H-float is optional, and emulated when absent.
> 
> packed-decimal[movp,cmpp3,cmpp4,addp4,addp6,subp4,subp6,
> cvtlp/pl,cvtpt/tp/ps/sp,sashp,mulp,divp) is optional, and emulated 
> (mostly by microvaxes).
> 
> Later processors (after 86) could (and did) omit 2 groups of instructions:
>  MATCHC,MOVTC,MOVTUC,CRC and EDITPC
>  ACB[FDGH}, emod[FDGH] and POLY[FDGH]
>
> And, of course the entire vector instruction set (I was responsible for 
> that emulator).
>
> Although in theory these were included or emulated as a group, some 
> implementations were selective.  VMS does not rely on model-specific 
> knowledge: it checks each opocode and loads the emulator if any 
> instruction is emulated.  Those that are implemented never reach it.
>
> Last I knew, SimH implements all instructions on all models (except vectors :-().

I haven't looked lately, but Bob originally implemented exactly what existed in the VAX780 and the CVAX (MicroVAX3900).  The other VAX simulators merely included what was already existing and made no specific effort to conform to implemented instructions precisely (for Example, I think the MicroVAX II and MicroVAX I simulators implement the same instructions as the CVAX).

> SimH's design goal is correctness, not particularly speed.  Except for 
> the -10, all run on a 32-bit platform.

That is true for the DEC system simulators, but as newer simulators have been implemented folks have used 64 bit data types when convenient.  Essentially all modern host systems, have compilers that deal with 64 bit data types in software, so that hasn't been a specific barrier.

> FWIW: there's room for optimization by promoting some internal representations to 64-bits where available.  But this is a big job, and would require a lot of validation.  Feel free to volunteer...

Volunteers are always welcome.

> I'm not sure where SimH stands on compiler optimizations - you can always try 
> compiling with the highest optimization level your compiler supports.  But 
> you may have to report some bugs...

The normal build compiles with the best optimizations we know to work.  When 
failures are observed or reported, if we can't fix the failing case, optimization 
levels are backed down.  A recent report, just last week, came up on OS X where
someone was running the HCORE diagnostic on the VAX750 simulator and a 
failure was now being reported for stuff that previously worked.  Compiling 
in debug mode (unoptimized) and the diagnostic passes.  Problems like this 
have come up a number of times as compiler implementations evolve.  Some
of the problems are implementation issues in the VAX simulator which Bob
initially did without strict regard to unsigned or signed integer values.  The
original simulator code was once run through the AXE tests suite to verify 
conformance to the architecture details.  I've taken a shot at rewriting the
things with consistent types, and the results run VMS and pass the basic 
HCORE diagnostics, but without the rigorous verification that AXE can provide
I don't feel comfortable committing this to the master branch.  If anyone can 
dig up or provide a way that the we can get someone to run this for us I
can move forward with the new implementation.  This approach would 
certainly seem better than the 'wack-a-mole' approach we've got now as
compilers change.

- Mark