[Simh] VAX/VMS

[Timothe Litt]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160216/1415fae7/attachment-0001.bin>