[Simh] Hardware fidelity in the VAX family simulators
First, congratulations to Mark for running the current Ultrix 750 problem to earth. Second, a brief diatribe about the need for fidelity to the hardware in the VAX simulators, which is (on the face of it) lacking outside the 3900 and 780 simulators. I have preached and documented the need for reasonable fidelity to hardware in implementing simulators. The papers on the SImH web site are filled with examples of minute details gumming up software behavior if a simulator gets them wrong. It looks to me like the 750, 730, 8600 are cut-and-paste jobs on the 780, and the MicroVAX I and II on the 3900. I admit there are strong family resemblances and, in some cases, reuse of hardware (the 8600 uses some of the 780 IO adapters), but as Ultrix proved, running VMS is an insufficient proof of correctness. Without reading (and implementing) the gory details of all the system-specific hardware, something is going to break. And if the goal is just to run VMS, why bother with variant models? The 780 and 3900 between them cover the complete history of VAX/VMS, Ultrix, and all the BSD variants. While the 750 now runs Ultrix, will it run the next OS it is given? Even with the current fix, there are multiple errors remaining in the UBA. The 730 won't boot Ultrix off the RB80; and so on. So my challenge to the community is twofold. First, is there more documentation on the variants available somewhere? I haven't found microcode sources or listings for the 750, 730, MicroVAX I, or 8600, for example. Second, are people prepared to "adopt" a model, read its documentation, and clean it up? End of diatribe. /Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 2015-07-08 23:39, Bob Supnik wrote: First, congratulations to Mark for running the current Ultrix 750 problem to earth. Second, a brief diatribe about the need for fidelity to the hardware in the VAX simulators, which is (on the face of it) lacking outside the 3900 and 780 simulators. I have preached and documented the need for reasonable fidelity to hardware in implementing simulators. The papers on the SImH web site are filled with examples of minute details gumming up software behavior if a simulator gets them wrong. It looks to me like the 750, 730, 8600 are cut-and-paste jobs on the 780, and the MicroVAX I and II on the 3900. I admit there are strong family resemblances and, in some cases, reuse of hardware (the 8600 uses some of the 780 IO adapters), but as Ultrix proved, running VMS is an insufficient proof of correctness. Without reading (and implementing) the gory details of all the system-specific hardware, something is going to break. And if the goal is just to run VMS, why bother with variant models? The 780 and 3900 between them cover the complete history of VAX/VMS, Ultrix, and all the BSD variants. While the 750 now runs Ultrix, will it run the next OS it is given? Even with the current fix, there are multiple errors remaining in the UBA. The 730 won't boot Ultrix off the RB80; and so on. So my challenge to the community is twofold. First, is there more documentation on the variants available somewhere? I haven't found microcode sources or listings for the 750, 730, MicroVAX I, or 8600, for example. Second, are people prepared to "adopt" a model, read its documentation, and clean it up? End of diatribe. I have certainly poked some at the 8600 in the past, which Mark knows. (And I have poked in the PDP-11/70 way way long ago, not sure if you even remember that one Bob). As time allows, I'm happy to poke more at the machines I know. (Mainly those two I guess...) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 08-Jul-15 17:39, Bob Supnik wrote: > The 780 and 3900 between them cover the complete history of VAX/VMS, > Ultrix, and all the BSD variants. Except for the VAX vector instructions... which GEM/Fortran knew about. As did the Digital Extended Math library (done by my group). But not much else. VMS has an emulator for those instructions (I wrote it). I don't believe it was ported to the Unix variants. (If it was, it was after I moved on and no one talked to me about it.) Vectors? What you add to an architecture just before you give up on it. Rigel and the 9000 supported VAX vectors. Alpha had them on its roadmap for Ev8 before it died... CDC's ETA-10 implemented vectors, and died. However, Cray and its clones had a good run. And of course there were the bolt-on 'array processors' for various machines. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
Sent from my handheld. More typos likely which is quite a thought. > On Jul 8, 2015, at 6:17 PM, Timothe Litt wrote: > > Vectors? What you add to an architecture just before you give up on it. > Rigel and the 9000 supported VAX vectors. Alpha had them on its roadmap for > Ev8 before it died... CDC's ETA-10 implemented vectors, and died. However, > Cray and its clones had a good run. And of course there were the bolt-on > 'array processors' for various machines. Tim Point taken and a reasonable observation. But to be fair most current architectures have them-they are pretty much deriger in the high end these days (along with lots of thread support). The key point is that the current compilers all generate code for them (thank you Mark, Dave, Kent, Rich et al who blazed the trail with Vax Fortran and then went on to 'reinject' that DNA into the current code base). Funny I listened to a google guy give a talk about LLVM today and many of the questions and concerns from our crew was how to get it to be as good as GEM or intel particular wrt vectors and the usual Fortran stuff. Fine for C but a long way to go for HPC. Also I don't think the Intel*64 architecture is going to die any time soon (nor Power for that matter). Fact is vectors are cute trick for fortran code and a good fortran implementation (particularly one that supported vectors and parallel execution) has paid many of our salaries over the years 😂 Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
>I haven't found microcode sources or listings for the 750, 730, > MicroVAX I, or 8600, for example. FWIW, the 725/730 was somewhat unique in that the micro store was entirely RAM. All of the microcode was loaded by the CFE at power on and none was in ROM. Also, the 730 micro engine was based on industry standard 29xx family bit slice parts. It was a little like the 11/60 in that it was easy, in theory at least, to write custom microcode. I've heard that certain customized versions of the 730 microcode were produced for special needs, and that DEC even supported this with some development tools, but I've never seen any such thing in the wild. So, if anyway if anybody does find the sources or development tools for the 730/725 microcode, I'd love to see a copy. Back to Bob's topic, I do have a running 730 system that could be powered on more or less any time. I'm willing to run tests if anybody needs to experiment with the behavior of real hardware. It's even on HECnet, so I could make remote access available. Bob Armstrong ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 2015-07-09 01:57, Robert Armstrong wrote: I haven't found microcode sources or listings for the 750, 730, MicroVAX I, or 8600, for example. FWIW, the 725/730 was somewhat unique in that the micro store was entirely RAM. All of the microcode was loaded by the CFE at power on and none was in ROM. Also, the 730 micro engine was based on industry standard 29xx family bit slice parts. It was a little like the 11/60 in that it was easy, in theory at least, to write custom microcode. I've heard that certain customized versions of the 730 microcode were produced for special needs, and that DEC even supported this with some development tools, but I've never seen any such thing in the wild. So, if anyway if anybody does find the sources or development tools for the 730/725 microcode, I'd love to see a copy. Back to Bob's topic, I do have a running 730 system that could be powered on more or less any time. I'm willing to run tests if anybody needs to experiment with the behavior of real hardware. It's even on HECnet, so I could make remote access available. The 86x0 machines also have the microcode in RAM. It's all loaded from the FE RL02 at start up. I have the documentation for all the microcode machines of the 86x0, but I don't have the actual microcode sources, nor the tools used to build the binaries. That said, I guess it should be doable to disassemble the existing microcode if one really wanted to. The 11/60 was an interesting machine in that DEC actually provided the tools for customers to write their own microcode. The 11/750 had RAM to store patches to the microcode, but the basic version of the microcode was in ROM. Where did the 11/725 and 11/730 load their microcode from. Surely not the TU58... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 2015-07-09 02:16, Robert G. Schaffrath wrote: On Jul 8, 2015, at 8:10 PM, Johnny Billquist wrote: On 2015-07-09 01:57, Robert Armstrong wrote: I haven't found microcode sources or listings for the 750, 730, MicroVAX I, or 8600, for example. FWIW, the 725/730 was somewhat unique in that the micro store was entirely RAM. All of the microcode was loaded by the CFE at power on and none was in ROM. Also, the 730 micro engine was based on industry standard 29xx family bit slice parts. It was a little like the 11/60 in that it was easy, in theory at least, to write custom microcode. I've heard that certain customized versions of the 730 microcode were produced for special needs, and that DEC even supported this with some development tools, but I've never seen any such thing in the wild. So, if anyway if anybody does find the sources or development tools for the 730/725 microcode, I'd love to see a copy. Back to Bob's topic, I do have a running 730 system that could be powered on more or less any time. I'm willing to run tests if anybody needs to experiment with the behavior of real hardware. It's even on HECnet, so I could make remote access available. The 86x0 machines also have the microcode in RAM. It's all loaded from the FE RL02 at start up. I have the documentation for all the microcode machines of the 86x0, but I don't have the actual microcode sources, nor the tools used to build the binaries. That said, I guess it should be doable to disassemble the existing microcode if one really wanted to. The 11/60 was an interesting machine in that DEC actually provided the tools for customers to write their own microcode. The 11/750 had RAM to store patches to the microcode, but the basic version of the microcode was in ROM. Where did the 11/725 and 11/730 load their microcode from. Surely not the TU58... You nailed it. That pathetically slow tape drive was used to load the microcode. I had an 11/730 at my first job 29 years ago and the wait to get the bootstrap was interminable! That is horrible. Even thinking of being absolutely dependent on a TU58 to even start the machine is bad. Not to mention slow... Surprised as well, as they did it better on the 11/750 (I think), where you don't need the TU58 for normal operation, but you still had the ability to patch the microcode as needed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
>Even thinking of being absolutely dependent on a TU58 to even start the > machine is bad. Not to mention slow... Just don't turn it off :-) Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
STABACK for the 730 was 3 or 4 TU58s, with the command parse table on the last tape, When I typed BACUP, it would spend about 5 minutes running the tape forward and rewinding until it concluded there was no such command… After the TU80 was added, I could boot from the RL02 and backup the R80 to tape. The Math Dept. instructor who was in charge but had never managed VMS (well, neither had I…) had me exactly once run a backup/image/log/verify to the LA120 console. Sean > On Jul 8, 2015, at 5:32 PM, Robert Armstrong wrote: > >> Even thinking of being absolutely dependent on a TU58 to even start the >> machine is bad. Not to mention slow... > > Just don't turn it off :-) > > Bob > > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On Wed, Jul 8, 2015 at 8:10 PM, Johnny Billquist wrote: >>> I haven't found microcode sources or listings for the 750, 730, >>> MicroVAX I, or 8600, for example. >> >>FWIW, the 725/730 was somewhat unique in that the micro store was >> entirely RAM. All of the microcode was loaded by the CFE at power on and >> none was in ROM. Also, the 730 micro engine was based on industry standard >> 29xx family bit slice parts. Yep. >>So, if anyway if anybody does find the sources or development tools for >> the 730/725 microcode, I'd love to see a copy. I'd love to see it too, just to get an idea of what's really under the hood there. > The 11/750 had RAM to store patches to the microcode, but the basic version > of the microcode was in ROM. I remember having to keep the microcode patch TU58 installed at some point after 1992 or so, because it would be slurped in when needed. It's not like were moving data over that drive. > Where did the 11/725 and 11/730 load their microcode from. Surely not the > TU58... Yep. Takes about 20 minutes unless you optimize the files in order of request... then it's about 5 minutes. -ethan ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 08-Jul-15 19:55, Clem cole wrote:
>
> Sent from my handheld. More typos likely which is quite a thought.
>
>> On Jul 8, 2015, at 6:17 PM, Timothe Litt wrote:
>>
>> Vectors? What you add to an architecture just before you give up on it.
>> Rigel and the 9000 supported VAX vectors. Alpha had them on its roadmap
>> for Ev8 before it died... CDC's ETA-10 implemented vectors, and died.
>> However, Cray and its clones had a good run. And of course there were the
>> bolt-on 'array processors' for various machines.
> Tim
>
> Point taken and a reasonable observation. But to be fair most current
> architectures have them-they are pretty much deriger in the high end these
> days (along with lots of thread support). The key point is that the current
> compilers all generate code for them (thank you Mark, Dave, Kent, Rich et al
> who blazed the trail with Vax Fortran and then went on to 'reinject' that DNA
> into the current code base).
>
> Funny I listened to a google guy give a talk about LLVM today and many of the
> questions and concerns from our crew was how to get it to be as good as GEM
> or intel particular wrt vectors and the usual Fortran stuff. Fine for C but
> a long way to go for HPC.
>
> Also I don't think the Intel*64 architecture is going to die any time soon
> (nor Power for that matter). Fact is vectors are cute trick for fortran
> code and a good fortran implementation (particularly one that supported
> vectors and parallel execution) has paid many of our salaries over the years 😂
>
> Clem
I was mostly thinking of long vectors. Current machines have SIMD
instruction sets with 8-16 vector registers ("short vectors") vs. the
64+ of the machines that pioneered vectors for HPC. The SIMD
instructions started as graphics accelerators; it took a few iterations
before they became more generally useful. And outside the high end, the
adoption rates were an issue due to the compatibility morass.
I agree that IA is the exception - certainly not on its technical
merits, but rather on its inertia. Power seems to be hanging on. And I
wasn't commenting on the merits of vectors, just when they appear in the
evolution of architectures.
Not all the enabling work for vectors was in the compiler space. The
VAX vector emulator actually has 2 variants; one that I did for the
FORTRAN/GEM team was designed to ensure that they obeyed the
architecture (not the implementations). It had hooks that allowed
arbitrary rescheduling of instructions between the various sync points,
traces & other instrumentation. Besides finding compiler bugs, it
caused one architecture ECO where the compiler folks said "hardware
would never do that, but the spec said OK". I probably should have done
a paper on it, but I was too busy creating stuff to write papers... The
production version was initially opposed by the compiler team, who felt
that it could never be fast enough to be useful. I was unwilling to
break the strict binary compatibility precedents for VAX. (vs. the IA
mess) I used quite a few coding tricks to end up beating the hurdle
(slowdown for emulation) that we agreed upon. The emulator made it
possible to have vector support at FRS (First Revenue Ship) of
hardware. I don't believe there were any cases where the emulator and
either hardware implementation diverged. (Of course, the emulator was
also the reference model for the hardware simulators...)
But on the original topic, for the reasons you note the VAX vector
instruction set is historically interesting. The primary point is that
absent OS emulation of vectors, SimH doesn't "cover the complete
history" of the VAX software stack. I haven't looked at implementing
VAX vectors in SimH. While one would expect to be able to build on the
scalar instruction emulations, condition codes and exceptions (math and
memory management) make it a project...even for the (simpler)
synchronous memory model variant.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On Jul 8, 2015, at 5:39 PM, Bob Supnik wrote: > First, congratulations to Mark for running the current Ultrix 750 problem to > earth. > > Second, a brief diatribe about the need for fidelity to the hardware in the > VAX simulators, which is (on the face of it) lacking outside the 3900 and 780 > simulators. > > I have preached and documented the need for reasonable fidelity to hardware > in implementing simulators. The papers on the SImH web site are filled with > examples of minute details gumming up software behavior if a simulator gets > them wrong. It looks to me like the 750, 730, 8600 are cut-and-paste jobs on > the 780, and the MicroVAX I and II on the 3900. I admit there are strong > family resemblances and, in some cases, reuse of hardware (the 8600 uses some > of the 780 IO adapters), but as Ultrix proved, running VMS is an insufficient > proof of correctness. Without reading (and implementing) the gory details of > all the system-specific hardware, something is going to break. And if the > goal is just to run VMS, why bother with variant models? The 780 and 3900 > between them cover the complete history of VAX/VMS, Ultrix, and all the BSD > variants. > > While the 750 now runs Ultrix, will it run the next OS it is given? Even with > the current fix, there are multiple errors remaining in the UBA. The 730 > won't boot Ultrix off the RB80; and so on. > > So my challenge to the community is twofold. First, is there more > documentation on the variants available somewhere? I haven't found microcode > sources or listings for the 750, 730, MicroVAX I, or 8600, for example. > Second, are people prepared to "adopt" a model, read its documentation, and > clean it up? > > End of diatribe. > > /Bob Let’s not forget different peripheral usage models between the various OSs. I have an open issue where Ultrix 2.0/2.2 run fine on a Microvax II, but as soon as I enable DECnet the system panics with: panic: qe: Non existent memory interrupt Mark, were you able to reproduce this problem with the updated image I pointed you at? John. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On 08/07/2015 22:39, Bob Supnik wrote: > It looks to me like the 750, 730, 8600 are cut-and-paste jobs on the > 780, and the MicroVAX I and II on the 3900. I admit there are strong > family resemblances and, in some cases, reuse of hardware (the 8600 > uses some of the 780 IO adapters), but as Ultrix proved, running VMS > is an insufficient proof of correctness. Without reading (and > implementing) the gory details of all the system-specific hardware, > something is going to break. Yes, they were. It was the best I could do at the time as I had almost no knowledge of the VAX architecture when I started writing these simulators. My first encounter with a VAX (and VMS) was in 2005 during my university work experience year (although to this day I've never seen a real 730, 750, 8600 or MicroVAX I). The available documentation wasn't always clear about how certain components should work and in these cases the correct functionality had to be inferred from VMS and Ultrix source listings. > And if the goal is just to run VMS, why bother with variant models? Because I thought it would be fun and that I might learn something by doing it. Both objectives were achieved. > The 780 and 3900 between them cover the complete history of VAX/VMS, > Ultrix, and all the BSD variants. Although you do need the VAXstation I or VAXstation II to run VWS. > So my challenge to the community is twofold. First, is there more > documentation on the variants available somewhere? I haven't found > microcode sources or listings for the 750, 730, MicroVAX I, or 8600, > for example. Second, are people prepared to "adopt" a model, read its > documentation, and clean it up? I hope so. I never expected them to be 100% perfect but I was hopeful that the community based testing and development would eventually ensure they worked correctly. Matt ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Hardware fidelity in the VAX family simulators
On Thursday, July 9, 2015 at 4:03 PM, Matt Burke wrote: > On 08/07/2015 22:39, Bob Supnik wrote: > > It looks to me like the 750, 730, 8600 are cut-and-paste jobs on the > > 780, and the MicroVAX I and II on the 3900. I admit there are strong > > family resemblances and, in some cases, reuse of hardware (the 8600 > > uses some of the 780 IO adapters), but as Ultrix proved, running VMS > > is an insufficient proof of correctness. Without reading (and > > implementing) the gory details of all the system-specific hardware, > > something is going to break. > > Yes, they were. It was the best I could do at the time as I had almost > no knowledge of the VAX architecture when I started writing these > simulators. My first encounter with a VAX (and VMS) was in 2005 during > my university work experience year (although to this day I've never seen > a real 730, 750, 8600 or MicroVAX I). > > The available documentation wasn't always clear about how certain > components should work and in these cases the correct functionality had > to be inferred from VMS and Ultrix source listings. Given that background you did an amazing job A true digital archeologist. > > And if the goal is just to run VMS, why bother with variant models? > > Because I thought it would be fun and that I might learn something by > doing it. Both objectives were achieved. > > > The 780 and 3900 between them cover the complete history of VAX/VMS, > > Ultrix, and all the BSD variants. > > Although you do need the VAXstation I or VAXstation II to run VWS. Good point, and this drove the addition of video support to the simh framework (by you!). > > So my challenge to the community is twofold. First, is there more > > documentation on the variants available somewhere? I haven't found > > microcode sources or listings for the 750, 730, MicroVAX I, or 8600, > > for example. Second, are people prepared to "adopt" a model, read its > > documentation, and clean it up? > > I hope so. I never expected them to be 100% perfect but I was hopeful > that the community based testing and development would eventually ensure > they worked correctly. Numerous interesting issues have already been identified and fixed since these other systems have been added to the simh codebase. Like Bob says, it would be great if more formal information was available. Most folks here are users of these systems and not really simulator developers. It is these folks who find the issues that with these newer simulators and the original ones. Sometimes they provide or suggest fixes, but in any case, bringing the issues to the attention on the list here and in the github issue system (https://github.com/simh/simh/issues) is how we improve the results. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
