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. 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. You should probably examine the register on your physical system - I would expect that NVAX either added codes to the CVAX set, or started over with a new enum. I don't remember which. > 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. > 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 :-(). SimH's design goal is correctness, not particularly speed. Except for the -10, all run on a 32-bit platform. 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... 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...
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
