[Simh] VAX/VMS

[Johnny Billquist]

Clem, you are right, and this have diverged a lot. I should have written 
it just to you instead. I apologize to all.
I'm going to make the following reply public anyway, but I'm going to 
try and stop after this. I think that the main point Clem makes is one I 
agree with anyway, so it's not that there is much to argue about. So 
this is mostly small comments on a couple of details.

On 2016-02-21 14:50, Clem Cole wrote:
> 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.

Agreed. On all points above. The fact that you can boot an old version 
of DOS on current hardware should be enough of a point to stop the 
discussion right now.

> 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.

And that is also the case for the other companies mentioned. The Alpha, 
for example, is not VAX compatible. And noone argues that this means 
that the VAX wasn't fairly consistent as an architecture. Just because 
you have one architecture does not mean you cannot ever make a different 
one.

> 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.

Yes. And I'm surprised if anyone would claim that Intel was breaking 
some rule just because they wanted to make a chip that did not use the 
same ISA as the x86.

> 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.

Well, it is a bit more complicated than that. The original x86 is 
Intels. The AMD extension is AMDs. AMD and Intel have a cross licensing 
agreement which means they can each use each others extensions and 
changes without any costs/legal issues/whatever. So, it's become a case 
of no matter who originally did it, both can implement it. So it's a 
case of, whatever is successful will be implemented by both, no matter 
who did it first. And both can extend the architecture. I guess in a way 
it's a case of the market decides.

> 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 can't comment on Amdahl, as I don't know enough, but for Cal Data, 
it's not in any way meaningful to compare with the x86.

> 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.

True. But most likely scenario is that had Intel not decided to use the 
AMD extension, the product would have been dead. The market was already 
established, and software was being written for it. Systems were already 
being shipped, and the reason for the success was the backward 
compatibility.
Yes, we cannot know for sure, but it is extremely unlikely that Intel 
would have been successful if they had tried pushing yet another, 
incompatible (with AMD64) 64-bit architecture at the same time they were 
trying to convince everyone that they should shift to Itanium.

> 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.

Agreed. And the fact is that the current "Intel 64" ISA is pretty much 
backwards compatible with the AMD64 is another case of "backward 
compatible". I think one additional point here is that this has been an 
important part of the success.

> For the record, the main system I run at home as “ccc.com
> <http://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.

So, you are not running "Intel 64", and yet it just works, without doing 
anything different. I guess you know what I was going to say next... ;-)
"Intel 64" is just a name. It don't really mean anything.

> 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.

Hah! I'm all with you. The x86 was an ugly child already when it was 
born. The years have not made it any prettier...
Yes, I suspect lots of people lament the Alpha, but that's what the 
market decided...

> 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.

I'm happy to leave things as they are now. I hope you don't disagree 
with too much of what I wrote.

Another thing I might say, though, is that in a way, the market might 
have caused the right thing to occur. But at the same time, it might 
have caused the wrong thing to occur. We now pretty much do not have any 
options for architectures. The market have eliminated that option for 
us. Good from an economical point of view, not so good from a bunch of 
other views...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol