[Simh] VAX/VMS

[Clem Cole]

This discussion has very much diverged from the original topics of VAX/VMS
and ISA compatibility.  If folks want to discuss the actions or inactions,
who did what *etc*… let’s take that off list.



I will try to come back to what I started with: Some people on this list
(including me), believe that Intel has done a pretty reasonable job of
compatibility as it moved from generation to generation from its original
4004 microprocessor to today’s Intel*64 ISA   From reading the comments,
others may not think the Intel team did, fair enough.    Also, other firms
such as IBM and DEC had done the same with their ISA (S360 and Vax in those
cases).



As has been pointed out, each of three firms mentioned have injected some
level of incompatibility along the way.   The question of how a good a job
they did is likely to be gauged on how it affected you personally.   I
personally find the ability to be able to boot a really old OS and run
really old programs on a modern chip to be handy.  Since this is a forum on
simulation, I would have thought others considered that a pretty important
feature.  But maybe it is not.   To pick on DEC (or IBM), the later
generations of their respective ISAs cannot boot the older OS – which
Intel’s primary ISA can – and that is what started this discussion.



I have also pointed out (as have others) that Intel also did not try to be
compatible with all its lines, which others consider that a negative for
Intel’s commitment to compatibility.



In fact is in almost every case except one that I can think, when Intel
broke away from the compatibility path that became today's INTEL*64 ISA,
Intel was not as successful in the market (I'm thinking i432, 860, 960,
Itanium) – the one success I can think of where they were not compatible
and were still successful was in their embedded line which was originally
the 8748 (which became the 8051).  I suppose it also can be pointed out
that the 860/960 ended up have a fairly long life also in the embedded
space and were "successful" there.  But those ISAs were eventually EOL’s;
while you can still find 8051 ISA based chips being manufactured today.



Others in this list seem to object to the fact the current INTEL*64 ISA is
owned and defined by Intel, not by a competing firm who originally created
an extension to the x86 (ney IA-32) ISA before Intel and brought it to
market in their product line.   Fair enough and I personally think I
understand why people might believe that and I do understand and lived the
same history.  But I point out that it does not change the fact that Intel
owns and defines ISA, it >>is<< Intel’s ISA.  Someone else does not get to
call it something else when they do not own it.   Just as the PDP-11, Vax &
Alpha were DEC’s ISAs and S360, S/370 & Power is/was IBM’s.



Think about 2 other instances, Cal Data extended the PDP-11 before DEC did
and Amdahl the S/360 before IBM.  As it turns out, DEC sued and put Cal
Data out of business but IBM let Amdahl be.   In both cases features first
pioneered on those other product lines, end up in the original (although
maybe with a different name and/or different implementation).   But the ISA
stayed S/360 and PDP-11 and the owners of each further extended their ISA
along the way (S/370, now zSeries, PDP-11 begat VAX 11/780).



I ask you for a minute to consider this set of facts.   When the engineers
at Intel did decide to extend IA32 to 64 bits (which was after others had
done it), the Intel engineering team could have created a set of extensions
to the x86 family that was different from others currently on the market.
We can all guess, but none of us on this list or elsewhere will ever know
if taking that design choice would have been successful -- as that choice
was made 15 years ago.  I think we might agree that a good bit of chaos
would have been brought to us as programmers.


Instead, the Intel engineers started with an existing set of extensions,
and added too (and continued to add too) that list.  Intel has brought out
many devices since that time and the market has moved on.     The choices
made by the Intel team does not lessen or make greater the work done by
Intel or it’s competitors.   It is what it is.   I believe that what
matters to us as programmers, is that our code runs on those devices – *that
they are compatible *- the topic of this discussion.   That is to say, I am
happy a different path was not chosen.   It certainly made my own choices
simpler.



For the record, the main system I run at home as “ccc.com” happens to be on
an Opteron and have no reason to change it.   It has a good bit of SCSI
storage on it, as well a number of different types of tapes.   It “just
works” and OpenBSD runs fine “out of the box”.    The truth is if I changed
it, I’m probably more likely to switch to an unused Tru64 based DS10 with
an Alpha in it than an Intel processor because I have one in the basement
that is currently turned off.  However, that system does not have as many
free SCSI channels as the Opteron does and the OpenBSD box just works.   So
it remains with lots of fan, noise and heat, as it is.





Also, as a computer scientist, I personally detest the technical aspects of
INTEL*64 ISA.   For an ISA, I’m unabashedly an Alpha believer.   But the
fact is DEC broke from compatibility when the Alpha was created.  And as
has been pointed out Intel/HP did the same with Itanium.      But unlike
DEC, which threw everything into Alpha, Intel did not abandoned x86.  Once
the team at Intel was realized that IA32 could have a future, the company
started to reinvest.   And when Alpha failed in the market (for whatever
reasons), sadly Alpha died.



Which brings be to my primary point about compatibility.   Compatibility is
an economic argument, not a technical one and we often forget that.  I am
glad that because Intel decided to stay in (come back too) the main stream
business (IA32) and created INTEL*64 for them to compete, the price was
driven down.   As a consumer, I believe that having options is good.   I
personally think this is a case where the market caused the right thing to
occur.



‘nuf said – so unless you want to talk about the compatibility thread,
 please take it off line.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160221/e643cc20/attachment-0001.html>