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

Reply via email to