[Simh] VAX/VMS

[Johnny Billquist]

Clem, I'm in a way not surprised that Intel pretends it invented and 
owns this, but I'm a bit sad if you do not acknowledge history. But 
maybe you cannot because of company policy or something. What do I know?
However, noone in a sane state of mind believes that Intel invented the 
64 bit extensions to the x86.
The truth is well known, and you can read up on it from Wikipedia, or 
why not just read the original AMD specification from 2000.
(https://en.wikipedia.org/wiki/X86-64, https://en.wikipedia.org/wiki/AMD_K8)

Intel was *not* planning to extend the x86 to 64 bits. Intel had a plan 
for 64 bit computing, and it was called Itanium. However, as we all 
know, Itanium had problems, and was slow to the market (and was not 
delivering on the performance promises either). Meanwhile AMD decided to 
do a 64 bit extension to the x86 instead, and got that to the market, 
and customers loved it. Pretty much all larger companies had committed 
to Itanium, but once AMD pushed their 64 bit x86 out, companies started 
to falter, and one after another, they dumped their Itanium plans, until 
only HP was left (which is where we are today). Meanwhile everybody was 
jumping on the x86-64 bandwagon, and Intel also realized they needed to 
be there. Yes, Intel owns the "Intel 64" name. Who cares? Noone uses 
that name (well, maybe except for Intel). Intel didn't even call it 
"Intel 64" from the start. Earlier they used the names "IA-32e" and "EM64T".
AMD owns the "AMD64" name. Few uses that name either.
Most people just call it "x86-64", or "x64".

The first processor released that implemented the x86-64 instruction set 
was the AMD K8.

Yes, additional extensions have been done to the instruction set since, 
but they are extensions, not changes. The latest Intel processors can 
still run the code that is compiled for the AMD K8.

For a more complete list of some details that do differ, see 
https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64. 
The truth is that for common people, the differences are irrelevant, and 
more feel like political bickering, and ways of being able to say "we 
did not copy the AMD solution", while in reality they did.
Like I said, the AMD K8 was first, and a program written for that 
processor will in reality run also on the latest Intel processor.

Intel didn't choose that the "Intel 64" should be backwards compatible. 
It was already decided. Intel itself had already chosen an incompatible 
way forward - the Itanium. The "Intel 64" was merely Intel's copy of the 
AMD64.

We, the consumers, benefited (well, maybe) from the fact that AMD 
decided to do a backward compatible 64-bit extension to the x86. And 
that Intel picked that up (and sortof gave up on the Itanium, even if 
that one is taking a long time to die. But it's getting close now...)



Anyway, that's that.


As far as compatibility goes, like we both said, Intel have been 
ensuring backward compatibility all along. Anyone who claims/blame them 
for not doing that just don't know what they are talking about. (Unless 
we talk about when Intel knowingly have not been backward compatible, 
but that is ok. The Itanium was not meant to be backwards compatible, 
nor was the iAPX432, i860 or i960, but all have failed. But that's a 
different story.)

	Johnny


On 2016-02-17 15:20, Clem Cole wrote:
> For whatever it is worth, this was a discussion about compatibility.  My
> point was and is, Intel owns the trademark; and defines / continues to
> extend the INTEL*64 and IA-32 ISA's.  The current definition can be
> found at:
> http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
>
> Intel has invested heavily in the ability to moved customer codes from
> 4004 to today's Phi ISA and IMO, done an excellent job of it.
> Certainly from the 386 family and later.  As Johnny and I both said, you
> can run MS-DOS and old DOS programs on my current system from an Edison
> (IoT) module that costs a few dollars all the way up to a world largest
> supercomputer (the Milky Way 2 system in China) - which is a bit of a
> frightening thought to me.
>
> As Tim points out, the cost to do that compatibility is huge on the
> development / investment side. As I said, the on-die tax has been
> reported to me my my brethren as about 5 %.
>
> So coming back to compatibility, when the first processors to support
> INTEL*64 were created, Intel's engineering team had a choice.   What is
> interesting is that Intel's engineers chose to ensure that current set
> of applications codes continued to run.   They did not have too.   We
> might have had two completely different instruction sets if they had
> chosen otherwise.  I personally think, we as consumers won because of that.
>
> IMO: I think that would have been a bad thing for developers because a
> number of choices would need to be made and confusion would have likely
> arisen.   That said, if you look at Apple's use of Fat Binaries, it
> might have been manageable if Linux and Windows had done something like
> that and the different compilers generated code that way.   As it turns
> out, that is not so far fetched, since we are doing that today for Phi,
> but the difference is that Intel owns both definitions and builds a
> single set of development tools so that the differences to user is unseen.
>
> Frankly, I'm personally glad that the folks that made decision took the
> path of starting with an existing set of extensions.   But that was
> 10-15 years ago.   Intel has continued to extend the ISA since that time
> and I believe that we will see that going on into the future. As I said,
> we already see more extensions with the Phi product line.    But back to
> my point, a pure core binary programs will run on a Phi, although today,
> Phi programs will need to be emulated on Core (until such time as the
> Phi features and extensions make it into the primary ISA).   Will that
> happen?  I can not say, but given the history of Intel, I would suspect
> it might because compatibility has been something Intel has heavily
> invested.
>
> I probably should add in all of these comments, they are my own and not
> necessarily those of my employer.  That said, I openly point out that
> I'm a Sr. Architect in the HPC team @ Intel.
>
> Clem
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

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