There is a commonly held fallacy that there is one single x86 instruction set. In reality, while all x86 chips run about 99% similar instructions, no two suppliers run exactly the same base. We have a different set to Intel, which is a different set to Via and so on. In fact, one of the things that differentiates our server line from Intel’s is that they don’t even have the same set of functions across the Nehalem line – where as we run all the same functions on the entire  family of Quad-Core AMD Opteron^TM processors.

This is one of the reasons why AMD Opteron processor-based servers make such good disaster recover solutions  – you really can failover running virtual machines  to newer, smaller standby systems without worrying that some of the processor functions may not be supported.

While the AMD Opteron processor retains backward compatibility, it is fair to point out that as we deliver new function at each generation, we often have to add extensions to the x86 instruction set (examples are virtualization and 64-bit extensions).

Changing the instruction set can be both complex and expensive for application developers and painful for system designers. AMD recognizes this, and we are trying to reduce some of this cost and complexity by helping to unify the x86 instruction set with the adoption of the Advanced Vector Extensions (AVX).

AMD has always been a champion of open and industry standards, and by adopting the AVX instructions for x86 processors initially announced by Intel in 2008, we can help move this ideal forward. We believe that by proposing and embracing enhancements to the instruction set, AMD provides software developers with a great step towards a more standard platform for innovation.

Now, originally we had focused on what we had called SSE5, a specification we proposed for review by the industry in 2007. However, due to the overlap of functionality between the AVX instructions and SSE5, AMD has decided to recast the SSE5 instructions into the AVX framework.  AMD made decision to ensure the continued compatibility of x86 software, and plans to incorporate AVX instructions into AMD processors in 2011.

And, still, we want to continue to advance the ball. In addition to embracing the AVX specification, AMD is proposing further enhancement to the current version of this specification called eXtended Operations (XOP). Given there are features of the SSE5 specification that were positively reviewed in the news and not in the current version of AVX, we have incorporated them into the new proposal. Examples of the functionality include:

• Supporting Enhanced Vectorization
• Accelerating traditional DSP Multi-Media algorithms
• Accelerating floating point algorithms for High Performance Computing

If you want to review the AVX or XOP, AMD is posting theses specification here.  I also encourage you to go read a blog written by Dave Christie, a Fellow in our Design Engineering team, to get more insight into the technical details and read what some of our technology partners have to say about this change.

You know, when I hear people cry, “Do not fork the x86 instruction set!” what I really hear is people saying, “Give up driving instruction set innovations!”

Well, there are two reasons why this won’t happen:

• Innovation ‘R US. We believe that bringing innovation to the market is one of our key values and we plan to continue to do what we can to bring users systems that better serve their needs
• There really isn’t a single static x86 instruction set and we need as an industry to make evolution of this instruction set. That’s why we publish changes we are proposing for discussion (and haven’t done it in secret). Our users and the application developers may have good ideas too.

The x86 instruction set will continue to evolve and change and wouldn’t it be great if we could do it together?

Nigel Dessau is senior vice president and chief marketing officer at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such links sites and no endorsement is implied.