<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">        <a href="http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html">http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 %.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.   </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Clem</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div>