Your opinions do coincide highly with your employer's :)

Give credit where credit is due:  AMD was the one that expanded the instruction set so you could run all of your IA-32 applications and 64-bit apps at the same time without the use of emulators or bolting another core onto the die...which is what Intel did with Itanium.

Intel was busy pushing IA-64 (Itanium) as the future and when AMD released the AMD64 extensions, it took Intel 4 years to release an implementation.  Intel has expanded the instruction set since then (as has AMD), which is a good thing, but it was AMD that set us on this course.

Brian

On 02/17/2016 09:20 AM, 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:

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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to