On 16-Feb-16 08:53, Johnny Billquist wrote: > On 2016-02-16 13:58, Timothe Litt wrote: >> On 16-Feb-16 06:49, Johnny Billquist wrote: >>> More precisely, V7.3 will run on *any* VAX, including the primal >>>> VAX-11/780. This level of backwards compatibility is unique. >>> >>> And there are some VAXen on which V7.3 will definitely not run. How >>> about rtVAX for example. >> Not fair. No version of VMS ever ran on rtVAX - it was designed that >> way. (For yes, marketing reasons.) > > Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm > did claim that VMS ran on *any* VAX. > I was also tempted to drag up the VXT1200. But since that one does not > have the name "VAX" in it, it could perhaps technically be > disqualified on that basis... The rtVAX on the other had is without a > doubt a VAX, even in name. It would have been more accurate for WIlm to say "any VAX that VMS was ever was released to run on"(1), which is still a strong statement.
As pointed out, somewhat stronger than the IBM forward compatibility story. DEC was obsessive about forward and backward compatibility. I even made sure that you could run vectorized programs on a 780. Or SimH (via the OS-delivered transparent instruction emulation.) And the architecture was managed to ensure that there are very few differences at the hardware level for the OS to paper over, even in privileged modes. (Mostly I/O bus evolution and error handling. Not layers of microcode and emulation required by others, including IBM and Intel.) This was also visible in the small effort required to port other VAX OSs (Ultrix, System V, and ELN) , though some of them chose to require kernel builds rather than the VMS approach of loadable kernel modules. Diagnostics were also beneficiaries. And the I/O devices [including disk and network adapters] that used VAXes (rarely rtVAXes, bTW) as embedded controllers. Most of those ran no OS, just a polling/tasking loop. Architecture management was a big effort. It delivered remarkable results. It wasn't free. It did slow innovation. And hardware always had to have a power-up mode that was backward-compatible where that was physically possible. (We didn't insist that you be able to plug an XMI peripheral directly into a 780 Unibus. Though you could have a UBA on a BI on an XMI on a JBox, and aside from a few registers initialized by the OS, your old device driver didn't know the difference.) Inside DEC, the PDP-6/10/20 line made similar guarantees and results. However, the process for accomplishing that was less rigorous. We didn't have the architectural conformance verification infrastructure (e.g. axe, paxe and max) that was developed for VAX from day one. The PDP-11 carried an instruction set forward in the same tradition. Mostly compatibly, but with a lot more user-visible variation. Multiple floating point add-ons and the commercial instruction set. Some instruction oddities, not all intentional. Not to mention memory management variations. It was a *lot* more work for an OS to adapt to a new -11. The VAX architecture process was a reaction to that. The PDP-8 family also provided a lot of compatibility via an ad-hoc process. It, too, had a fair bit of user-visible variation. You could write code that would run on any family member, but it wasn't automatic. With VAX, it is. Nonetheless, Brooks (@IBM) definitely gets credit for the first commercial line of architecturally (forward) compatible machines. Prior to that inspiration, every new machine was unique and most software started over (including compilers). rtVAX *is* architecturally *almost* a VAX. It is listed in the architecture documents as "the rtVAX variant", and was a separate product line. The VAX name, and the ability for user level code (at least in the VAX/ELN supported languages) to run on it were valid technical and marketing features. But you would no more expect VMS to run on ANY rtVAX than you would expect a gasoline-powered auto to run on diesel. Yes, there is a lot of similarity. The engines even look very similar. But the design is explicitly for one or the other. ++++ (1) Phrased that way to cover the cases of machines that ran VMS internally at one point, but were killed and the provisional support removed from VMS. (2) As for VXT, I don't remember what it used internally. But there were a couple of versions of that device, and if there was a processor upgrade, its software also benefited from the strong forward and backward compatibility of the VAX. It might have shipped different firmware because of the graphics upgrades or other choices it made. But the processor wouldn't have driven that.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh