The thing is your arguments there are not correct and I see no reason that anyone should take your words for granted. Besides, isn't copy-and-paste some basic computer skill? It's so easy and I'll do it for you here. I'll even comment on them in-line.
Actually it is Intel using completely different coding scheme for AVX, which with the new scheme completely replaces the instruction formats of SSE - SSE4.2. In contrast AMD's SSE5 simply adds a DREX to the instructions and leaves the format of SSE - SSE4a intact.
In any case this is not programmer's problem because compilers should take care of that.
You first say we should do something, then say that something has little hope. I don't know what's your logic or what are you talking about???
I see no reason that later SSE5.x can't add support for 3-operand or 4-operand to other SSE media instructions by using the immediate byte like AVX does. The only reason that it doesn't seems to be that current SSE5 attempts to make minimum changes to existing instruction formats.
SSE5 does not make instructions longer. SSE5 instructions are as long as SSE3 instructions (2-byte prefix plus 1-byte opcode). AVX makes some SSE3/SSE4 instructions 1-byte shorter under 64-bit mode because it absorbs the functionality of REX. In all other cases the AVX format makes instructions longer.
This is completely false. SSE5 is so simple that it can be described in 2 pages. AVX is so complex that the even smalls things like register names and formats are different for different operating modes or instructions. Some AVX instructions can use both 2 and 3 byte VEX, some can use only 3 byte VEX. Sometimes a register in AVX is taken 1's compliment and sometimes it is not. Sometimes at some position AVX can specify a memory argument and sometimes it cannot. Sorry but there is no "sanitation" at all but deliberate complication.
I don't see why SSE5 can't have room for further extension. There are unused opcodes and unused prefix available. If AMD so wanted they can even recycle opcodes from 3DNow for SSE5.x. Besides, the merit of an ISA extension is not in how much it can be extended, but how useful its extensions are.
VEX is basically a way for Intel to say "sorry we messed up the instruction from MMX to SSE to SSE4.1 and SSE4.2, now we're going to fix them up by messing up the instruction format a bit more." The problem is not how the instructions are cramped into a 3-byte word, but how the instructions have overlapping and specialized functionality among them.
To add insult to injury (from the prospect of ISA quality), there is no "different formats of identical instructions" in AVX and SSE5 (because instructions in these two are different), but there are different formats of identical instructions in AVX itself alone. "Ingenious," indeed. Like AMD64, NO.
The only "advantage" of AVX over SSE5 is 256-bit registers and 4-operand operations. However, AVX also has less powerful compare/permutation instructions, but more semantic and syntactic restrictions on the use of its instructions than SSE5. Furthermore, it will probably be easier for AMD to implement SSE5 than for Intel to implement AVX. I seriously doubt that Intel made AVX so complicated to ensure that nobody (else) can implement it easily. A good SSE5 and SSEplus implementation will be easier to use and cheaper to implement than AVX.
I don't think you understand the difference between SSE5 and AVX, and that between SSE5 and 3DNow. Had you actually studied it and understood it, you'd have found that SSE5 instructions are very generic. They are applicable to a wide range of situations. AVX instructions OTOH are quite specific and has operation requirements that make you wonder where did those come from. In terms of ISA design SSE5 is clearly better than AVX.
As for 3DNow, it was not comparable to the depth or width of SSE5 at all. There were less than 20 instructions in 3DNow and they are all focused on floating point operations. In contrast SSE5 offers 80 some new instructions (not including different operating modes of the same opcode) covering all kinds generic operations. The number of new instructions offered by SSE5 is even more than that offered by AVX. Your "claim" has been totally contrary to reality, and thus I don't believe your "prediction" bears any credibility either.
When AMD published their new ISA extension named SSE5 in late August 2007, they also introduced a new instruction code format for instructions with 3 or 4 operands. When Intel presented their AVX extension in April this year they introduced another code format that also supports 3 or 4 operands. These two formats are very different. We are now in a position where AMD and Intel are using completely different coding schemes for the same instructions.
Actually it is Intel using completely different coding scheme for AVX, which with the new scheme completely replaces the instruction formats of SSE - SSE4.2. In contrast AMD's SSE5 simply adds a DREX to the instructions and leaves the format of SSE - SSE4a intact.
This is every programmer's nightmare! I cannot imagine any significant number of programmers making three versions of their code: one for AMD, one for Intel, and one for compatibility with older processors.
In any case this is not programmer's problem because compilers should take care of that.
The forking of instruction sets and coding schemes is one of the less desirable consequences of free competition. We would all prefer some kind of international standardization committee that could approve new instruction codes. Such a committee would be reluctant to accept new shortsighted patches that add just another complication to instruction decoding. They would have weeded out the bizarre undocumented instructions from the old 8086 days that are still supported. And they might not accept the addition of new instructions to the already bulging instruction set mainly for marketing reasons with little technical benefit. Unfortunately, there is little hope that such a committee will be formed.
You first say we should do something, then say that something has little hope. I don't know what's your logic or what are you talking about???
I have looked into the details of the two competing instruction formats and made a comparison:
* Both ISA extensions are compatible with all existing code.
* SSE5 supports 3 operands for new instructions only. AVX extends existing instructions to 3 operands as well. Almost all existing instructions on XMM registers are extended to 3 operands, and the code format makes room for also extending general-purpose register instructions to 3 operands.
* SSE5 supports instructions with 4 operands, but only if two of the operands are the same register. AVX supports any combination of 4 registers by adding an extra code byte. Future extension to 5 operands is possible.
I see no reason that later SSE5.x can't add support for 3-operand or 4-operand to other SSE media instructions by using the immediate byte like AVX does. The only reason that it doesn't seems to be that current SSE5 attempts to make minimum changes to existing instruction formats.
* SSE5 makes instructions longer. AVX makes some instructions longer and some instructions shorter, but most instructions keep the same length as before despite containing one more register operand and other new information.
SSE5 does not make instructions longer. SSE5 instructions are as long as SSE3 instructions (2-byte prefix plus 1-byte opcode). AVX makes some SSE3/SSE4 instructions 1-byte shorter under 64-bit mode because it absorbs the functionality of REX. In all other cases the AVX format makes instructions longer.
* SSE5 adds yet another complication to the already very complicated instruction decoding procedure. AVX makes instruction decoding simpler by sanitizing a lot of old patches. The many prefixes and escape bytes that pester the current instruction set are joined together into a single "VEX" prefix that is 2 or 3 bytes long.
This is completely false. SSE5 is so simple that it can be described in 2 pages. AVX is so complex that the even smalls things like register names and formats are different for different operating modes or instructions. Some AVX instructions can use both 2 and 3 byte VEX, some can use only 3 byte VEX. Sometimes a register in AVX is taken 1's compliment and sometimes it is not. Sometimes at some position AVX can specify a memory argument and sometimes it cannot. Sorry but there is no "sanitation" at all but deliberate complication.
* AVX supports the extension of the 128-bit vector registers (XMM registers) to 256 bits (YMM registers) with room for further extensions in the future. SSE5 has no room for new extensions.
* AVX has 3 unused bits for future extensions to the now overloaded opcode map. This means no new shortsighted patches for a foreseeable future.
I don't see why SSE5 can't have room for further extension. There are unused opcodes and unused prefix available. If AMD so wanted they can even recycle opcodes from 3DNow for SSE5.x. Besides, the merit of an ISA extension is not in how much it can be extended, but how useful its extensions are.
Before I saw the AVX documentation, I would have denied that it was possible to add so much new information without making instructions longer. The trick is that it makes one long prefix instead of many short prefixes. One or a few bits in the new VEX prefix contains the same information as a whole 8-bit or even 16-bit prefix or escape code in the current coding scheme. The two VEX prefixes are made out of two obsolete instructions, LDS and LES, which are valid in 16- and 32-bit mode but invalid in 64-bit mode. Certain bits in the VEX prefix that indicate register extensions available only in 64-bit mode are placed in such a way in the VEX prefix that the only values valid in 32-bit mode form an invalid register operand if interpreted as a legacy LDS or LES instruction. This is a solution no less ingenious than the x64 extension invented by AMD.
VEX is basically a way for Intel to say "sorry we messed up the instruction from MMX to SSE to SSE4.1 and SSE4.2, now we're going to fix them up by messing up the instruction format a bit more." The problem is not how the instructions are cramped into a 3-byte word, but how the instructions have overlapping and specialized functionality among them.
To add insult to injury (from the prospect of ISA quality), there is no "different formats of identical instructions" in AVX and SSE5 (because instructions in these two are different), but there are different formats of identical instructions in AVX itself alone. "Ingenious," indeed. Like AMD64, NO.
Looking at the advantages of AVX over SSE5 there can be no doubt that AMD has no choice but to adopt AVX. There is no way AMD can stay in competition without supporting the new 256-bit vectors and the 3-operand version of all existing XMM instructions. And, incidentally, it will be easier to implement the new 3-operand instructions for AMD than it is for Intel because the current Intel microarchitecture does not allow micro-operations with more than two inputs, while the AMD microarchitecture has no such limitation.
The only "advantage" of AVX over SSE5 is 256-bit registers and 4-operand operations. However, AVX also has less powerful compare/permutation instructions, but more semantic and syntactic restrictions on the use of its instructions than SSE5. Furthermore, it will probably be easier for AMD to implement SSE5 than for Intel to implement AVX. I seriously doubt that Intel made AVX so complicated to ensure that nobody (else) can implement it easily. A good SSE5 and SSEplus implementation will be easier to use and cheaper to implement than AVX.
Let me explain the advantage of 3-operand instructions to those who don't know what this is about. Most of the current instructions place the result of a calculation in the same register as one of the input operands, e.g.:
A = A * B.
With a 3-operand version, you can do:
C = A * B.
This gives the programmer the freedom to reuse the original value of A in other calculations without having to copy it to another register. The result is fewer register-to-register moves and hence more efficient and compact code.
The SSE5 instructions will suffer the same fate as AMD's 3DNow instructions. Nobody ever used the 3DNow instructions because they are not supported in Intel processors. They are superseded by the more efficient SSE instructions, but AMD have to keep supporting them in all their future processors for the sake of backwards compatibility. Let's hope that AMD have the guts to drop SSE5 altogether before it's too late. There has been some speculation that they might.
Too bad that AMD haven't seen this coming before they published their SSE5 spec. Intel must have been able to keep their plans secret despite the patent sharing agreement between AMD and Intel. Maybe there is no patent on AVX?
I don't think you understand the difference between SSE5 and AVX, and that between SSE5 and 3DNow. Had you actually studied it and understood it, you'd have found that SSE5 instructions are very generic. They are applicable to a wide range of situations. AVX instructions OTOH are quite specific and has operation requirements that make you wonder where did those come from. In terms of ISA design SSE5 is clearly better than AVX.
As for 3DNow, it was not comparable to the depth or width of SSE5 at all. There were less than 20 instructions in 3DNow and they are all focused on floating point operations. In contrast SSE5 offers 80 some new instructions (not including different operating modes of the same opcode) covering all kinds generic operations. The number of new instructions offered by SSE5 is even more than that offered by AVX. Your "claim" has been totally contrary to reality, and thus I don't believe your "prediction" bears any credibility either.
The only way to persuade a big bad boy Intel is to do something like what AMD did with its own x86-64. I think that it will be reasonably to develop a RISC-like ISA (let's name it, say, RISC86 
), compatible with x86-64 at instruction mnemonics, but not compatible at the binary code. If all the general players on the x86-market (both software and hardware ones: Microsoft, GNU/Linux creators, AMD, VIA/Centaur, nVidia, quite not sure about Intel) will support this new RISC86 ISA by creating a public standardization committee, it woud be an ideal situation. In this case many problems can be solved.
), compatible with x86-64 at instruction mnemonics, but not compatible at the binary code. If all the general players on the x86-market (both software and hardware ones: Microsoft, GNU/Linux creators, AMD, VIA/Centaur, nVidia, quite not sure about Intel) will support this new RISC86 ISA by creating a public standardization committee, it woud be an ideal situation. In this case many problems can be solved.
A new RISC instruction set? Intel did that first with Itanium - not a big success 
The market wants compatibility, not on the assembly language level but on the binary level. A new ISA will have to be compatible with existing code. A microprocessor that supports both x86 and RISC86 would probably be accepted by the market, but it might end up running x86 code faster than RISC86 because the CISC code takes less space in the code cache than RISC code.
Well, speaking of RISC86 I have meant just another new operating mode plus to three already existing: x86-16, x86-32, x86-64... and RISC86 . All of us know that every of three existing x86-modes (16, 32, 64 bits) has its own decode rules (I mean a binary code), so why not to start from the scratch and eliminate (almost?) all the x86-problems in the fourth new RISC86-mode?:
1) a different length of instructions;
2) an ugly x87 instructions;
3) an ugly instruction encoding with lots of escape prefices;
4) a brake a.k.a rFLAGS which is significally slows down instruction execution;
5) no more than two operands for the most instructions;
6) what else?
About Itanium: I would like to say that Intel, this BBB (big bad boy), does want a lots of money for its IA64, but AMD doesn't for its x86-64 at all. That's the huge difference. Did you watch the Guy Ritchie's "Revolver" movie? If yes, do you remember what Lord John did say?: "But there is no angel as destructive as their greed, in the end she gets them all." I would like to repeat another phrase (not from the movie😞 "World needs open standards." Do you remember which are they ?
About instruction cache capacity: I'm not quiet sure that, in general, CISC code will be much more compact than RISC86 one. Maybe slightly.
. All of us know that every of three existing x86-modes (16, 32, 64 bits) has its own decode rules (I mean a binary code), so why not to start from the scratch and eliminate (almost?) all the x86-problems in the fourth new RISC86-mode?: 1) a different length of instructions;
2) an ugly x87 instructions;
3) an ugly instruction encoding with lots of escape prefices;
4) a brake a.k.a rFLAGS which is significally slows down instruction execution;
5) no more than two operands for the most instructions;
6) what else
? About Itanium: I would like to say that Intel, this BBB (big bad boy), does want a lots of money for its IA64, but AMD doesn't for its x86-64 at all. That's the huge difference. Did you watch the Guy Ritchie's "Revolver" movie? If yes, do you remember what Lord John did say?: "But there is no angel as destructive as their greed, in the end she gets them all." I would like to repeat another phrase (not from the movie
😞 "World needs open standards." Do you remember which are they ? About instruction cache capacity: I'm not quiet sure that, in general, CISC code will be much more compact than RISC86 one. Maybe slightly.
agner: You've said: "from the software industry". I think that it would be a charcoal, which will ignite the petition's bonfire. And you could be the match .
When I've told about an online petition, I've meant www.petitiononline.com, most famous site of that kind. Would you try to start this petiton? I think that first your message at this topic is perfect as the base.
I believe that your initiative would be more productive in the online petition form .
Good news: AMD have changed the specifications for the future SSE5 instructions to make them more compatible with Intel's AVX scheme, see: http://support.amd.com/us/Processor_TechDocs/43479.pdf
To avoid confusion, they have also changed the name SSE5 to XOP, FMA4 and CVT16.
Thank you so much, AMD. Please tell us if Bulldozer will support both XOP, FMA4 and CVT16?
Bad news: Intel have recently changed the specs for their FMA instructions, so that the compatibility is lost again.
How ironic:
In the initial preliminary specifications, AMD had 3 different operands on FMA instructions, and Intel had 4 operands.
Now, both companies have revised their specifications: AMD now has 4 operands on FMA instructions and Intel has 3 operands isgust;.
Apparently, Intel are to blame for not informing AMD in time about this change. They certainly knew that AMD planned to make compatible instructions because there have been patent sharing negotiations about this issue.
Maintaining compatibility seems to be a game of running after a moving target, as long as both companies keep secrets for each other rather than cooperate.
Can somebody from AMD please comment on how you will react to Intel's latest change in their FMA spec. Will future AMD processors use 3 or 4 operands on FMA instructions, or support both forms?
Agner: It seems that AMD has heard you . But, alas, Intel did a dirty trick 
.
Originally posted by: avk Agner: It seems that AMD has heard you
Yes, AMD have certainly done what I have argued so heavily for here and elsewhere - thank you very much for that - but I have no idea whether they would have done the same had I not voiced my opinion. I don't know what the motives behind Intel's change was.
All these problems could be avoided if we had a public forum for discussion of new instructions, supported by both Intel and AMD.
