Discussion:
[Simh] VAX emulation issues on Raspberry Pi
Jeremy Begg
2018-07-30 22:57:26 UTC
Permalink
Hi,

A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.

The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.

On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.

On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.

I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.

The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example

$ ./vax < vax.ini

the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.

A similar issue occurs if I try to load the boot console NVR from a file:
the VAX console boot ROM fails its self-test and won't boot VMS.

The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.

The SIMH version is currently

MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9

I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.

Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.

FWIW the Raspberry Pi is running

Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux

and the file /etc/os-release is:

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
Here is the full SHOW VERSION output:

sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Host Platform:
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at 08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 733ac0d9

The later version (which I'm not running because it didn't fix the startup issues) is:

sim> show version
MicroVAX 3900 simulator V4.0-0 Current
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Host Platform:
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at 21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00


Thanks,

Jeremy Begg

+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: ***@vsm.com.au |
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
Robert Armstrong
2018-07-31 00:03:56 UTC
Permalink
Post by Jeremy Begg
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster.
FWIW, that's only 12x faster (for whatever that means in this situation!), not 120x ....

Bob
Timothe Litt
2018-07-31 01:03:00 UTC
Permalink
Two issues have been discussed before.

The boot failures are being worked by Mark - they're some timing issue
having to do with the fact that SimH is faster than the hardware.  They
seem to be a heisenbug.  He's recently added instrumentation.

The SSH startup isn't compute bound so much as entropy limited.  This
was discussed a while ago, but I don't recall the final outcome.  Check
the archives.

The 4000/96 would be a NVAX or NVAX+.  It would require more license
units than the 3900, so I'm somewhat surprised that you're having
issues.  But LMF has lots of ways to evaluate licenses.  The SID
register reflects the CPU type; SYS_TYPE has the licensing bits.  The
SID determines which VMS CPULOA is loaded - this is what I/O buses are
supported, machine check format - you can't change it without a lot more
grief.  The SYS_TYPE bits are the workstation vs. server.  There's SimH
support for that.
Post by Jeremy Begg
Hi,
A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.
On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.
On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.
I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.
The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example
$ ./vax < vax.ini
the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.
the VAX console boot ROM fails its self-test and won't boot VMS.
The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.
The SIMH version is currently
MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9
I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.
Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.
FWIW the Raspberry Pi is running
Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at 08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 733ac0d9
sim> show version
MicroVAX 3900 simulator V4.0-0 Current
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at 21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
Zane Healy
2018-07-31 01:05:14 UTC
Permalink
Don’t forget SIMH is emulating a lot more than just the CPU, it also has to emulate all the rest of the hardware that makes up a VAX.

My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a i7-3770 CPU @ 3.40GHz (which is starved for RAM), SIMH/VAX on a VM running on it clocks in at about 34.6 VUPS. I have a i5-3470 @ 3.2Ghz and SIMH runs at about 31.6 VUPS. If you have a top of the line, current i7, you might be able to get close to the speed of your VAXstation 4000/96.

I’ve been buying used HP SFF desktop boxes to use as servers, I pick them up used for almost nothing. A few months ago, that i5 cost me $75, I think the i7 was less than $200. Wiped the drive, put Linux on it, and now the SIMH/VAX instance on it provides most of the storage for my VMS Cluster.

Right now most of my VMS environment at home has been replaced by emulation. Once I move PDXVAX off of a VAXstation 4000/60 (it’s my DECnet area router), I’ll be running a fully emulated environment. Honestly it’s something of a relief. Though I am considering looking into running one physical machine as a desktop, booting it into my cluster.

Instead of starting SIMH like this:
$ ./vax < vax.ini
Try:
$ ./vax vax.ini

All my VMS systems are using Telnet right now, as I don’t have any VMS system running a modern version of SSH. I’ve also not managed to get DECwindows to work right with any X-Windows on my current systems (it works fine with my SGI O2). This is one of the reasons I’m considering running a physical VMS system as a desktop.

You bring up a very good point on the licensing though. I’m not sure what to suggest there. :-(

Zane
Post by Jeremy Begg
Hi,
A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.
On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.
On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.
I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.
The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example
$ ./vax < vax.ini
the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.
the VAX console boot ROM fails its self-test and won't boot VMS.
The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.
The SIMH version is currently
MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9
I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.
Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.
FWIW the Raspberry Pi is running
Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at 08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 733ac0d9
sim> show version
MicroVAX 3900 simulator V4.0-0 Current
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at 21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
Jeremy Begg
2018-07-31 05:31:11 UTC
Permalink
Hi Zane,

Firstly, thank you all for the quick responses. And yes I made a mistake in
calculating the relative (raw) CPU performance of my VAXstation vs Raspberry
Pi; the Pi is indeed only 12 times the clock speed of the VAXstation.
Don't forget SIMH is emulating a lot more than just the CPU, it also has to
emulate all the rest of the hardware that makes up a VAX.
Indeed, although where it's slowest appears to be floating point. Which has
got me thinking about my choice of emulated VAX, or about the rigour of the
emulation. More on this in a moment.
My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a i7-3770
about 31.6 VUPS. If you have a top of the line, current i7, you might be
able to get close to the speed of your VAXstation 4000/96.
Interesting. One of the reasons I went for the RPi solution was to keep
power consumption to a minimum but given the VAXstation consumed about 100W
I could obviously go to a reasonably powered server to get the performance.
$ ./vax < vax.ini
$ ./vax vax.ini
I will. I might also experiment with the SIMH "expect" functionality.
All my VMS systems are using Telnet right now, as I don't have any VMS
system running a modern version of SSH. I've also not managed to get
DECwindows to work right with any X-Windows on my current systems (it works
fine with my SGI O2). This is one of the reasons I'm considering running a
physical VMS system as a desktop.
In my experience with recent X11 servers (anything released in the last
several years) the only permitted clients are those running on the local
host or via an SSH session with X-Auth forwarding enabled. I suspect it's
possible to enable less secure access controls but it looks like you have to
jump through hoops to get there.
You bring up a very good point on the licensing though. I'm not sure what
to suggest there. :-(
The license wouldn't be an issue if the SET CPU MODEL command worked.

And in response to Timothe Litte,
Two issues have been discussed before.
The boot failures are being worked by Mark - they're some timing issue
having to do with the fact that SimH is faster than the hardware. They
seem to be a heisenbug. He's recently added instrumentation.
It just seems curious that taking the SIMH commands from a file rather than
the keyboard should make any difference. The emulated VAX isn't even
started at that point.
The SSH startup isn't compute bound so much as entropy limited. This
was discussed a while ago, but I don't recall the final outcome. Check
the archives.
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 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 4000/96 would be a NVAX or NVAX+. It would require more license
units than the 3900, so I'm somewhat surprised that you're having
issues. But LMF has lots of ways to evaluate licenses. The SID
register reflects the CPU type; SYS_TYPE has the licensing bits. The
SID determines which VMS CPULOA is loaded - this is what I/O buses are
supported, machine check format - you can't change it without a lot more
grief. The SYS_TYPE bits are the workstation vs. server. There's SimH
support for that.
There's a SIMH "SET CPU MODEL" command which supposedly lets it switch
between MicroVAX3900 and VAXserver3900, but the command has no effect and
the machine always boots as a VAXserver -- which required the somewhat
obscure availability table code "B" licence. (I've never seen one in the
wild, and I have a folder full of original VAX licence PAKs.)

FWIW, on this machine the SID = 0x0A000006 and SHOW CPU says:

ERIC, a VAXserver 3900 Series
Multiprocessing is DISABLED. Uniprocessing synchronization image loaded.

PRIMARY CPU = 00
Active CPUs: 00
Configured CPUs: 00

Thanks,

Jeremy Begg
Post by Jeremy Begg
Hi,
A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.
On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.
On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.
I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.
The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example
$ ./vax < vax.ini
the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.
the VAX console boot ROM fails its self-test and won't boot VMS.
The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.
The SIMH version is currently
MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9
I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.
Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.
FWIW the Raspberry Pi is running
Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at 08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 733ac0d9
sim> show version
MicroVAX 3900 simulator V4.0-0 Current
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at 21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
Johnny Billquist
2018-07-31 08:44:27 UTC
Permalink
A couple of comments.

On the issue of starting up, I guess it depends on what kind of error
you get when. But in general, I would agree with Zane. Don't redirect
stdin. Give the config file as as argument instead. I would say that is
the canonical way of doing it.

Speedwise, 12 times faster clock, yes. You can pretty much bet that any
simulated VAX instruction ends up with more than 12 instructions in
simh, and clock cycles per instruction are probably not so much
different, so you can bet your hat that it's going to be slower in simh.

FPP - Every VAX have an FPP. Some of the early models had some
limitations, such as the MicroVAX I and VAX-11/730 not having support
for all floating point formats. But I'm pretty sure this is irrelevant
here, because I bet ssh is not doing a lot of floating point to start
with. It is doing a lot of math yes, but it is with large integers.
The reason floating point is slow, by the way, is because VAX floating
point is not IEEE. So, to correctly emulate it, you need to do even more
complex emulation than for any other part of the CPU, which takes way
more time. You cannot use the host machine floating point operations
straight up, and just give those results back. VAX floating point works
slightly differently.

So for ssh, it just takes that much time, because it is a lot of
calculations. I don't think entropy itself is the issue. I remember that
a big increase in performance came in NetBSD/vax when some of that code
was rewritten in pure assembler instead of being C code for the math.

Licencing... I can't remember the 3900 being available in more than one
form in real life, so I'm not sure there is any differentiation between
a MicroVAX 3900 and a VAXserver 3900. But I have not checked what the
command in simh actually does. But I guess someone is going to inform me
of the difference now. :-)

Johnny
Post by Jeremy Begg
Hi Zane,
Firstly, thank you all for the quick responses. And yes I made a mistake in
calculating the relative (raw) CPU performance of my VAXstation vs Raspberry
Pi; the Pi is indeed only 12 times the clock speed of the VAXstation.
Don't forget SIMH is emulating a lot more than just the CPU, it also has to
emulate all the rest of the hardware that makes up a VAX.
Indeed, although where it's slowest appears to be floating point. Which has
got me thinking about my choice of emulated VAX, or about the rigour of the
emulation. More on this in a moment.
My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a i7-3770
about 31.6 VUPS. If you have a top of the line, current i7, you might be
able to get close to the speed of your VAXstation 4000/96.
Interesting. One of the reasons I went for the RPi solution was to keep
power consumption to a minimum but given the VAXstation consumed about 100W
I could obviously go to a reasonably powered server to get the performance.
$ ./vax < vax.ini
$ ./vax vax.ini
I will. I might also experiment with the SIMH "expect" functionality.
All my VMS systems are using Telnet right now, as I don't have any VMS
system running a modern version of SSH. I've also not managed to get
DECwindows to work right with any X-Windows on my current systems (it works
fine with my SGI O2). This is one of the reasons I'm considering running a
physical VMS system as a desktop.
In my experience with recent X11 servers (anything released in the last
several years) the only permitted clients are those running on the local
host or via an SSH session with X-Auth forwarding enabled. I suspect it's
possible to enable less secure access controls but it looks like you have to
jump through hoops to get there.
You bring up a very good point on the licensing though. I'm not sure what
to suggest there. :-(
The license wouldn't be an issue if the SET CPU MODEL command worked.
And in response to Timothe Litte,
Two issues have been discussed before.
The boot failures are being worked by Mark - they're some timing issue
having to do with the fact that SimH is faster than the hardware. They
seem to be a heisenbug. He's recently added instrumentation.
It just seems curious that taking the SIMH commands from a file rather than
the keyboard should make any difference. The emulated VAX isn't even
started at that point.
The SSH startup isn't compute bound so much as entropy limited. This
was discussed a while ago, but I don't recall the final outcome. Check
the archives.
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 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 4000/96 would be a NVAX or NVAX+.� It would require more license
units than the 3900, so I'm somewhat surprised that you're having
issues. But LMF has lots of ways to evaluate licenses. The SID
register reflects the CPU type; SYS_TYPE has the licensing bits. The
SID determines which VMS CPULOA is loaded - this is what I/O buses are
supported, machine check format - you can't change it without a lot more
grief. The SYS_TYPE bits are the workstation vs. server. There's SimH
support for that.
There's a SIMH "SET CPU MODEL" command which supposedly lets it switch
between MicroVAX3900 and VAXserver3900, but the command has no effect and
the machine always boots as a VAXserver -- which required the somewhat
obscure availability table code "B" licence. (I've never seen one in the
wild, and I have a folder full of original VAX licence PAKs.)
ERIC, a VAXserver 3900 Series
Multiprocessing is DISABLED. Uniprocessing synchronization image loaded.
PRIMARY CPU = 00
Active CPUs: 00
Configured CPUs: 00
Thanks,
Jeremy Begg
Post by Jeremy Begg
Hi,
A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.
On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.
On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.
I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.
The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example
$ ./vax < vax.ini
the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.
the VAX console boot ROM fails its self-test and won't boot VMS.
The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.
The SIMH version is currently
MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9
I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.
Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.
FWIW the Raspberry Pi is running
Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at 08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 733ac0d9
sim> show version
MicroVAX 3900 simulator V4.0-0 Current
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at 21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Timothe Litt
2018-07-31 12:48:00 UTC
Permalink
Post by Jeremy Begg
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.
Post by Jeremy Begg
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.
Post by Jeremy Begg
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...
Mark Pizzolato
2018-07-31 16:27:17 UTC
Permalink
Post by Jeremy Begg
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.
<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.
1 UV2, 4 Uv2000/vs2000, 5 VAXterm, 6 9000 console
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.
Post by Jeremy Begg
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.
Post by Jeremy Begg
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.
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).
  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
Paul Koning
2018-07-31 16:41:50 UTC
Permalink
Post by Mark Pizzolato
...
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.
One thing that happens with newer compilers is that they take more advantage of opportunities offered by the letter of the standard. If you do something that is "undefined", the compiler can do with that whatever it wants to. If you have code that appears to allow something undefined under certain conditions, the compiler is free to assume that the undefined thing cannot happen and therefore that scenario doesn't occur.

For example:
extern int foo[100];

if (i < 0)
a += foo[i];

The compiler is allowed to delete that code because subscripting an array with a negative number is undefined. And modern compilers often will.

There is an excellent paper, I think from MIT, about many undefined things in C that are not all that well understood by many programmers. Unfortunately I've misplaced the reference. It mentions that Linux turns off a whole pile of gcc optimizations by specific magic flags to avoid breaking things due to undefined things it does in the existing code base.

For integer arithmetic, what you mentioned is a key point. Unsigned is defined to have wraparound semantics. With signed integers, overflow is "undefined". So, for example, if you want to emulate the PDP11 arithmetic operations, you have to use unsigned short (uint16_t). Using signed short (int16_t) is incorrect because of the overflow rules.

More generally, in SIMH you probably want the rule that every integer variable is unsigned. Or at least, make every variable unsigned unless you know there is a good reason why it needs to be signed, and no undefined behavior is possible for that particular variable.

If you compile (in gcc) with -Wall and get no warnings, that's a pretty good sign. If you do get warnings, they almost certainly need to be fixed rather than disabled.

paul
Timothe Litt
2018-07-31 17:08:47 UTC
Permalink
Post by Paul Koning
One thing that happens with newer compilers is that they take more advantage of opportunities offered by the letter of the standard. If you do something that is "undefined", the compiler can do with that whatever it wants to. If you have code that appears to allow something undefined under certain conditions, the compiler is free to assume that the undefined thing cannot happen and therefore that scenario doesn't occur.
extern int foo[100];
if (i < 0)
a += foo[i];
The compiler is allowed to delete that code because subscripting an array with a negative number is undefined. And modern compilers often will.
There is an excellent paper, I think from MIT, about many undefined things in C that are not all that well understood by many programmers. Unfortunately I've misplaced the reference. It mentions that Linux turns off a whole pile of gcc optimizations by specific magic flags to avoid breaking things due to undefined things it does in the existing code base.
For integer arithmetic, what you mentioned is a key point. Unsigned is defined to have wraparound semantics. With signed integers, overflow is "undefined". So, for example, if you want to emulate the PDP11 arithmetic operations, you have to use unsigned short (uint16_t). Using signed short (int16_t) is incorrect because of the overflow rules.
More generally, in SIMH you probably want the rule that every integer variable is unsigned. Or at least, make every variable unsigned unless you know there is a good reason why it needs to be signed, and no undefined behavior is possible for that particular variable.
If you compile (in gcc) with -Wall and get no warnings, that's a pretty good sign. If you do get warnings, they almost certainly need to be fixed rather than disabled.
You probably mean
https://people.csail.mit.edu/nickolai/papers/wang-stack-tocs.pdf

For more reading, see, e.g. http://port70.net/~nsz/c/c99/n1256.html#J.2
<http://port70.net/%7Ensz/c/c99/n1256.html#J.2>,
https://cacm.acm.org/magazines/2016/3/198849-a-differential-approach-to-undefined-behavior-detection/fulltext,
https://blog.regehr.org/archives/1520,
https://runtimeverification.com/blog/undefined-behavior-review-and-rv-match/


The last is a competitive analysis - but quite informative nonetheless.

In additions to -Wall, I also used to compile SimH with -pedantic and
-Werror.  And usually one of the -std flags.

Another big potential gotcha in SimH is the heavy use of casts, and type
aliasing rules (the latter especially problematic in subroutine calls).
Paul Koning
2018-07-31 17:46:10 UTC
Permalink
Post by Paul Koning
One thing that happens with newer compilers is that they take more advantage of opportunities offered by the letter of the standard. If you do something that is "undefined", the compiler can do with that whatever it wants to. If you have code that appears to allow something undefined under certain conditions, the compiler is free to assume that the undefined thing cannot happen and therefore that scenario doesn't occur.
...
You probably mean https://people.csail.mit.edu/nickolai/papers/wang-stack-tocs.pdf
No, but thanks for that pointer. The paper I was thinking about is listed in the references:

Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, and M. Frans Kaashoek. 2012a. Undefined behavior: What happened to my code? In Proceedings of the 3rd Asia-Pacific Workshop on Systems.
For more reading, see, e.g. http://port70.net/~nsz/c/c99/n1256.html#J.2, https://cacm.acm.org/magazines/2016/3/198849-a-differential-approach-to-undefined-behavior-detection/fulltext, https://blog.regehr.org/archives/1520, https://runtimeverification.com/blog/undefined-behavior-review-and-rv-match/
The last is a competitive analysis - but quite informative nonetheless.
In additions to -Wall, I also used to compile SimH with -pedantic and -Werror. And usually one of the -std flags.
Hm, -pedantic is specificially intended to be "the warnings that aren't really useful for general use and real code".
Another big potential gotcha in SimH is the heavy use of casts, and type aliasing rules (the latter especially problematic in subroutine calls).
Yes, aliasing is a big problem area. If you get any warnings about strict aliasing, fixing them (via unions) is a good idea. Alternatively, fno-strict-aliasing can be used but that comes with a performance cost and is not the best answer.

paul
Timothe Litt
2018-07-31 18:18:04 UTC
Permalink
No, but thanks for that pointer. The paper I was thinking about is
Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, and M. Frans Kaashoek. 2012a. Undefined behavior: What happened to my code? In Proceedings of the 3rd Asia-Pacific Workshop on Systems.
https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf

Seems to be a rehash of some well-known stuff - that was pretty well
known even in 2012.

In additions to -Wall, I also used to compile SimH with -pedantic and -Werror. And usually one of the -std flags.
Hm, -pedantic is specificially intended to be "the warnings that aren't really useful for general use and real code".
But I often found that if I tripped one, my mind was wandering and
something else was likely not quite right :-)
Another big potential gotcha in SimH is the heavy use of casts, and type aliasing rules (the latter especially problematic in subroutine calls).
Yes, aliasing is a big problem area. If you get any warnings about strict aliasing, fixing them (via unions) is a good idea. Alternatively, fno-strict-aliasing can be used but that comes with a performance cost and is not the best answer.
I'm of the school that says "fix, don't disable".  Especially if you
want your code to work with more than one compiler.  But it can be
painful with legacy code.

I also recommend "C is not a low-level language
<https://queue.acm.org/detail.cfm?id=3212479>" in the July issue of
CACM.  It makes some useful points that apply here.
Jeremy Begg
2018-07-31 13:12:08 UTC
Permalink
Hi,

Thanks all for your further comments, and I stand corrected on the nature of
the calculations performed to set up an SSH session. I think at this point
I'll give up on the SSH and rework my remote access to the machine.
Post by Jeremy Begg
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.
Thanks for the detailed explanation, and it makes complete sense. I'll do
some experiments.

Regards,

Jeremy Begg
Robert Armstrong
2018-07-31 13:33:24 UTC
Permalink
Post by Zane Healy
My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a
and SIMH runs at about 31.6 VUPS
FWIW, this may also say something about the quality of the code generation in gcc for ARM vs x86 processors, or it may even say something about the relative efficiency of those two architectures.

I run a MicroVAX-3900 simh on an Intel Atom D525 based server continuously. There are lots of little, fanless, 12V powered (for UPS) Atom based servers out there, and they're pretty cheap and low power. I think mine averages about 10W, and that includes the SSD and the fan I had to stick in it because it got too hot in the network closet :-)

Empirically, just sitting there using the simulation, it feels about as fast as a real MicroVAX-II or III. Logging in via ssh, assuming you're using public key/private key authentication, does take forever to do the initial key exchange but once you're authenticated it's not bad.

Bob
Paul Koning
2018-07-31 14:08:39 UTC
Permalink
Post by Robert Armstrong
Post by Zane Healy
My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a
and SIMH runs at about 31.6 VUPS
FWIW, this may also say something about the quality of the code generation in gcc for ARM vs x86 processors, or it may even say something about the relative efficiency of those two architectures.
One thing worth doing is to use the latest gcc. Code generation keeps improving, and it's likely that architectures such as ARM see significant benefits in newer releases.

paul
Timothe Litt
2018-07-31 15:49:05 UTC
Permalink
Post by Paul Koning
Post by Robert Armstrong
FWIW, this may also say something about the quality of the code
generation in gcc for ARM vs x86 processors, or it may even say
something about the relative efficiency of those two architectures.
One thing worth doing is to use the latest gcc. Code generation keeps improving, and it's likely that architectures such as ARM see significant benefits in newer releases.
Bob's SimH shows:

Compiler: GCC 6.3.0 20170516

The latest gcc is 8.1.0.

It's a bit of a pain to build (I did it recently), but less so than in
years past.

On a Pi, it will take quite a while.  Be sure to use the latest
dependencies - gmp, mpc, mpfr.  And put in some place like /usr/local -
you don't want to replace the system compiler.

Read http://gcc.gnu.org/wiki/InstallingGCC &
https://gcc.gnu.org/install/index.html.

I haven't played with isl - it may help, or it may expose new issues.

You may be better off building a cross-compiler & building on a fast x86
or other platform if you have one.  Besides computes, I/O on the PI can
be pretty slow - USB is not a high-performance bus.  Especially if  you
need a bunch of hubs.

You also may need the latest binutils - if not for the build, for using
the compiler.  Somewhere between the version I used previously and the
new one, the object file format was enhanced incompatibly.

ARM is a RISCish architecture, x86 is a very CISC one, burdened with a
lot of backward compatibility.  Under the hood, it uses a lot of clever
optimizations.  Both are moving targets, as are their compilers.  (GCC
isn't the only choice.  Don't forget to try ICC if you want Intel's take
on optimized code for their CPUs.  And Clang is coming along.)  Don't
open the religious war over "relative efficiency"; the only thing that
matters is whether code that you care about has performance that you
deem adequate.

Have fun.
Henry Bent
2018-07-31 15:55:51 UTC
Permalink
Post by Robert Armstrong
FWIW, this may also say something about the quality of the code generation
in gcc for ARM vs x86 processors, or it may even say something about the
relative efficiency of those two architectures.
One thing worth doing is to use the latest gcc. Code generation keeps improving, and it's likely that architectures such as ARM see significant benefits in newer releases.
Compiler: GCC 6.3.0 20170516
The latest gcc is 8.1.0.
It's a bit of a pain to build (I did it recently), but less so than in
years past.
On a Pi, it will take quite a while. Be sure to use the latest
dependencies - gmp, mpc, mpfr. And put in some place like /usr/local - you
don't want to replace the system compiler.
Read http://gcc.gnu.org/wiki/InstallingGCC & https://gcc.gnu.org/install/
index.html.
I haven't played with isl - it may help, or it may expose new issues.
You may be better off building a cross-compiler & building on a fast x86
or other platform if you have one. Besides computes, I/O on the PI can be
pretty slow - USB is not a high-performance bus. Especially if you need a
bunch of hubs.
You also may need the latest binutils - if not for the build, for using
the compiler. Somewhere between the version I used previously and the new
one, the object file format was enhanced incompatibly.
ARM is a RISCish architecture, x86 is a very CISC one, burdened with a lot
of backward compatibility. Under the hood, it uses a lot of clever
optimizations. Both are moving targets, as are their compilers. (GCC
isn't the only choice. Don't forget to try ICC if you want Intel's take on
optimized code for their CPUs. And Clang is coming along.) Don't open the
religious war over "relative efficiency"; the only thing that matters is
whether code that you care about has performance that you deem adequate.
Have fun.
I did a writeup a while back about various compilers and SIMH on x86, here
is the link from the archive:
http://mailman.trailing-edge.com/pipermail/simh/2015-December/014102.html

Profile-guided feedback is extremely helpful for SIMH. If you are able to
recompile SIMH for your workload using feedback, the gains are extremely
significant.

-Henry
Paul Koning
2018-07-31 16:18:11 UTC
Permalink
Post by Paul Koning
Post by Robert Armstrong
FWIW, this may also say something about the quality of the code generation in gcc for ARM vs x86 processors, or it may even say something about the relative efficiency of those two architectures.
One thing worth doing is to use the latest gcc. Code generation keeps improving, and it's likely that architectures such as ARM see significant benefits in newer releases.
...
I did a writeup a while back about various compilers and SIMH on x86, here is the link from the archive: http://mailman.trailing-edge.com/pipermail/simh/2015-December/014102.html
Profile-guided feedback is extremely helpful for SIMH. If you are able to recompile SIMH for your workload using feedback, the gains are extremely significant.
Interesting, and not too surprising. Given that, it may be useful to use a recent GCC which supports LTO -- Link Time Optimization. That's a scheme that allows whole-program optimization, rather than the normal per-sourcefile optimization.

paul
Mark Pizzolato
2018-07-31 16:36:37 UTC
Permalink
Post by Robert Armstrong
Post by Paul Koning
Post by Robert Armstrong
FWIW, this may also say something about the quality of the code
generation in gcc for ARM vs x86 processors, or it may even say something
about the relative efficiency of those two architectures.
Post by Paul Koning
One thing worth doing is to use the latest gcc. Code generation keeps
improving, and it's likely that architectures such as ARM see significant benefits
in newer releases.
Post by Paul Koning
...
I did a writeup a while back about various compilers and SIMH on x86, here is
the link from the archive: http://mailman.trailing-
edge.com/pipermail/simh/2015-December/014102.html
Profile-guided feedback is extremely helpful for SIMH. If you are able to
recompile SIMH for your workload using feedback, the gains are extremely
significant.
I looked at Henry's stuff when he put it out, but it didn't lend itself to generic
inclusion in the base platform independent source.
Post by Robert Armstrong
Interesting, and not too surprising. Given that, it may be useful to use a recent
GCC which supports LTO -- Link Time Optimization. That's a scheme that allows
whole-program optimization, rather than the normal per-sourcefile
optimization.
LTO was actually the default for most environments a few years back, but
I think that was one of the first things that broke some simulators on some
platforms. It has been backed out when there were problems.

- Mark
Paul Koning
2018-07-31 17:06:17 UTC
Permalink
Post by Mark Pizzolato
...
Post by Paul Koning
Interesting, and not too surprising. Given that, it may be useful to use a recent
GCC which supports LTO -- Link Time Optimization. That's a scheme that allows
whole-program optimization, rather than the normal per-sourcefile
optimization.
LTO was actually the default for most environments a few years back, but
I think that was one of the first things that broke some simulators on some
platforms. It has been backed out when there were problems.
If that's still true with the latest GCC, especially with the in-development one (V9.0, from Subversion), those issues might be undefined code problems in SIMH. It is of course also possible that they are LTO bugs, in which case finding and reporting them would be a useful thing.

paul
Mark Pizzolato
2018-07-31 18:23:00 UTC
Permalink
Post by Mark Pizzolato
Post by Mark Pizzolato
...
Post by Paul Koning
Interesting, and not too surprising. Given that, it may be useful to
use a recent GCC which supports LTO -- Link Time Optimization.
That's a scheme that allows whole-program optimization, rather than
the normal per-sourcefile optimization.
LTO was actually the default for most environments a few years back,
but I think that was one of the first things that broke some
simulators on some platforms. It has been backed out when there were
problems.
If that's still true with the latest GCC, especially with the in-development one
(V9.0, from Subversion), those issues might be undefined code problems in
SIMH. It is of course also possible that they are LTO bugs, in which case finding
and reporting them would be a useful thing.
The preponderance of issues are undefined code problems. Given these
being pervasive, chasing down corner case problems that LTO might cause (and
identifying the actual details) hasn't been on the radar.

Being able to rigorously verify the reworked VAX code (and fix remaining or
newly introduced issues) would be a priority given the right tools.
I hope to hear back from Tim's contact to further this project.

Thanks.

- Mark

Clem Cole
2018-07-31 18:00:58 UTC
Permalink
I'm going to send this once here -- please take any follow up off line to
me privately. I don't want to seed a discussion of goodness or badness of
different compilers. This is purely as an FYI for those that may not be
aware.

*Comments are my own and do not neccessarily represent official policy.
This is all based on my observation as a user and consumer, and friend of
the developers.*
Don't forget to try ICC if you want Intel's take on optimized code for
their CPUs.
right.

FWIW: The intention of the icc (Intel C Compiler) team is to try really
hard to be the 'best' compiler for Intel's chips and targets the compilers
for ISV and high-end users that care about performance [example ISV is
Apple's "Final Cut", most CAD vendors like Abacus, Ansys and the like].
So much effort is spent by the team to try to know where the compiler
deviates from gcc (and LLVM and a number of other commercial compilers such
a MSFT, Cray and IBM). If you find something that might seem
strange please know that while I do not work on that team, I do each lunch
with those folks quite often/many are in the same building as me.

I can and have filed a bug reports so someone in the icc backend team looks
at it. Also, I note that icc/ifort *et al* are available for free for
personal/research use (and for FOSS projects like simh in fact - send me
info offline if you want to know more). That said, it does not always mean
the team will change the code generator when we file a report - as there
are some cases where icc prefers some optimizations over some taken by gcc
[sometimes it seems like taste - but their choices are based on
architectural differences where Intel has chosen one way to generate code
that makes more sense to their engineers for 'Genuine Intel' processors
that match the INTEL*64 definition, and not on other implementations of
that same architecture that Intel does not manufacture ... while gcc might
use a different scheme with different trade offs].


But so far in all cases, but one that I know about where we found a place
where gcc generated 'better' code for simh (*i.e.* a benchmark ran faster)
and I reported it. The icc team dug into why and icc was changed to do as
well or better. The one case where it was not (which was about 36 months
ago), it depended on the processor as it turns out and the Intel
optimization make more sense for the current or future 'big core' chips,
and they chose to keep that sequence. I have not re-run that sequence in
a while on my current i7 based Mac so I'm sure who it matches to be honest.
And Clang is coming along.
Indeed, in fact Intel compiler team has people that work on both gcc and
LLVM and very much want them to generate the best code they can. Clang
is an interesting compiler, particularly for the 'C Family' - [the LLVM
Fortran has a ways to go, but Intel is actually spending a lot of money to
help that team also as Intel's compiler folks really want to see an FOSS
'production quality 'modern' Fortran besides their own.
ᐧ
Loading...