[Simh] VAX emulation issues on Raspberry Pi

[Timothe Litt]

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...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180731/309aee70/attachment-0001.html>