Thoughts on "8 Core" Bulldozer and "4 Core Sandy Bridge"

[Idontcare]

I posted copied and pasted everthing YOU needed to KNOW. I ask JOHN for just 1 copy and paste. This is about BD and SB . Both claim AVX support . Which is true . But now John has stepped up a level and clains the prefix of Vex support . All he has to do is copy and paste . That 1 little Bit about the XOP prefix as thats the whole ballgame . He won't post it because its likely not there . Instead I will get this VEX crap. Without the XOPprevex wording as stated above in the vexprefix. AMD does not have such a prefixvex or the compilers to go along with it .

dude, for the love of Pete and the number 42, can we give it a rest already?

Let's just hypothesize for the moment, for the sake of argument, that you are 100% correct (make that 110% if it helps)...so the f*ck what?

Does it hasten the timeline for the end of the world? Can I then expect the rapture to arrive all the sooner? Does the moon spontaneously hurl itself into the earth owing to the massive gravitational flux caused by Intel's awesome greatness on that momentous occasion?

I can't buy it today, even if I could buy it today its not like it is going to open my junk-mail for me and take out the trash, there will still continue to be a myriad of other worldly problems that annoy me from day-to-day so its not like the uber-processor from Intel is going to solve world hunger or be the harbinger of world peace and usher in a new era of fusion-powered electricity and so on.

And that's giving you the best "you are right, Intel pwns all" scenario. Then what? I'm still betting the world+dog goes "meh" and carries on just as they did in the eighties and nineties...

 

[jones377]

I found this little gem under Definitions. Page 31

VEX prefix
Extended instruction identifier prefix, used by AVX, CLMUL, and FMA4 instructions.

 

[Outrage]

I posted copied and pasted everthing YOU needed to KNOW. I ask JOHN for just 1 copy and paste. This is about BD and SB . Both claim AVX support . Which is true . But now John has stepped up a level and clains the prefix of Vex support . All he has to do is copy and paste . That 1 little Bit about the XOP prefix as thats the whole ballgame . He won't post it because its likely not there . Instead I will get this VEX crap. Without the XOPprevex wording as stated above in the vexprefix. AMD does not have such a prefixvex or the compilers to go along with it .

1.2.2 Three-Byte Extended Prefix
All extended instructions can be encoded using a three-byte prefix. XOP instructions use only the three-byte prefix, but VEX-encoded instructions that comply with the constraints described in Section 1.2.3, “Two-Byte Extended Prefix” can also utilize a two-byte prefix. Figure 1-3 shows the format of the three-byte prefix

1.2.3 Two-Byte Extended Prefix
All extended instructions can be encoded using the three-byte prefix, but certain VEX-encoded instructions can also utilize a compact, two-byte prefix. XOP instructions do not use the two-byte prefix. The format of the two-byte prefix is shown in Figure 1-3.

game set and match.....

 

[Bearach]

I posted copied and pasted everthing YOU needed to KNOW. I ask JOHN for just 1 copy and paste. This is about BD and SB . Both claim AVX support . Which is true . But now John has stepped up a level and clains the prefix of Vex support . All he has to do is copy and paste . That 1 little Bit about the XOP prefix as thats the whole ballgame . He won't post it because its likely not there . Instead I will get this VEX crap. Without the XOPprevex wording as stated above in the vexprefix. AMD does not have such a prefixvex or the compilers to go along with it .

1.2.2.1 Prefix Byte 0
The value in this byte indicates the extended instruction type. AVX, CLMUL, and FMA4 instructions
use the VEX prefix; XOP instructions use the XOP prefix.​

• Byte 0 of the VEX prefix must be C4h for three-byte prefixes or C5h for two-byte prefixes.

• Byte 0 of the XOP prefix must be 8Fh, and all XOP instructions use a three-byte prefix.​

This at all what you're looking for? Its all over the document.​

 

[Nemesis 1]

dude, for the love of Pete and the number 42, can we give it a rest already?

Let's just hypothesize for the moment, for the sake of argument, that you are 100% correct (make that 110% if it helps)...so the f*ck what?

Does it hasten the timeline for the end of the world? Can I then expect the rapture to arrive all the sooner? Does the moon spontaneously hurl itself into the earth owing to the massive gravitational flux caused by Intel's awesome greatness on that momentous occasion?

I can't buy it today, even if I could buy it today its not like it is going to open my junk-mail for me and take out the trash, there will still continue to be a myriad of other worldly problems that annoy me from day-to-day so its not like the uber-processor from Intel is going to solve world hunger or be the harbinger of world peace and usher in a new era of fusion-powered electricity and so on.

And that's giving you the best "you are right, Intel pwns all" scenario. Then what? I'm still betting the world+dog goes "meh" and carries on just as they did in the eighties and nineties...

You and I both know there is no rapture. Personnal beliefs should have nothing to do with how you live your life now or in the future . Its one day after another and its all a struggle .

This isn't about e-penis its about truth or the lack there of . Think of it as a true false test. Facts is all I am tring to discover here . Is that not what hardware forums should be about . Rather than hype.

 

[Nemesis 1]

Well I was gonna post the number of times the words VEX and prefix appear in AMD's document but I don't think my old computer can handle such a big number.

What does that have to do with anything . Unless AMD XOP has bits encoded in its XOPprefix . were talking about something else all together . In an AMD PDF I would expect to see XOP and XOPprefix all over the place . Intel invented AVX not AMD . So one should expect to see Vex and Vex prefix all over the place . I can tell ya . AS of last week amd and intel had no agreement inplace on the exclusive rights to intels Vex prefix. AMD can use AVX and thats all they can use.

 

[Idontcare]

You and I both know there is no rapture. Personnal beliefs should have nothing to do with how you live your life now or in the future . Its one day after another and its all a struggle .

This isn't about e-penis its about truth or the lack there of . Think of it as a true false test. Facts is all I am tring to discover here . Is that not what hardware forums should be about . Rather than hype.

True.

But there is such a thing as beating the proverbial horse and I just can't help but get the impression from this thread that the horse...it done been beated to death already.

When you arrive at an impasse like this, as you appear to have arrived, isn't there a point where it becomes prudent to just take a break and jointly agree that "we shall see what comes when it comes"?

I'm there with BD. Beats the 2600K, beats the 990X, sucks more wind than a Phenom 965...none of the hype matters at this point because we simply have no purchasing opportunity. It is immaterial at this juncture.

I feel like the vex prefix matter has reached that point. It may have been of material relevance for a period of time, even in the cerebral context, but we've exceeded the bounds of reasonable discourse on the subject matter and at this time it really seems like a fruitless endeavor on all sides (the discussion of who has what, not the ISA itself).

 

[Nemesis 1]

I found this little gem under Definitions. Page 31

Good so tell me what it means. I am all ears I have a great desire to learn and I am 60 .

 

[jones377]

What does that have to do with anything . Unless AMD XOP has bits encoded in its XOPprefix . were talking about something else all together . In an AMD PDF I would expect to see XOP and XOPprefix all over the place . Intel invented AVX not AMD . So one should expect to see Vex and Vex prefix all over the place . I can tell ya . AS of last week amd and intel had no agreement inplace on the exclusive rights to intels Vex prefix. AMD can use AVX and thats all they can use.

Yea except the VEX prefix is inside every AVX instruction, which AMD implements. The documents, both AMD and Intel support this. The reason the XOP instructions uses the XOP prefix is because they are a left over from SSE5 proposed by AMD and then abandoned and transfered to AVX as XOP.

The bigger problem here is that you are unable to admit that you are wrong, unfortunately for us. Have you ever been wrong about anything in your life and admitted it Nemesis?

 

[jones377]

Good so tell me what it means. I am all ears I have a great desire to learn and I am 60 .

It means exactly what it says. I've no idea why you excluded it from the quote. (well I do actually)

 

[Nemesis 1]

True.

But there is such a thing as beating the proverbial horse and I just can't help but get the impression from this thread that the horse...it done been beated to death already.

When you arrive at an impasse like this, as you appear to have arrived, isn't there a point where it becomes prudent to just take a break and jointly agree that "we shall see what comes when it comes"?

I'm there with BD. Beats the 2600K, beats the 990X, sucks more wind than a Phenom 965...none of the hype matters at this point because we simply have no purchasing opportunity. It is immaterial at this juncture.

I feel like the vex prefix matter has reached that point. It may have been of material relevance for a period of time, even in the cerebral context, but we've exceeded the bounds of reasonable discourse on the subject matter and at this time it really seems like a fruitless endeavor on all sides (the discussion of who has what, not the ISA itself).

I would agree . Except for my first post after John revived this thread . You know ding dang well thats my argument. You likely have a good idea of how important this is also. After all it is from Intels PDF . Intel did invent AVX . Anyone can through the vex word around after all were discussing vectors. John said befor this post laid dorment That Intel had to pad the YMM in the upper half . and AMD wouldn't suffer from the delay that intel would suffer . Than I showed from intels PDF that Intel said it affected FMA . Yet you are attacking me . When I posted directly from Intels PDF. I took the Time to read Intels PDF although I type slow and badly I read remarkably fast .

 

[Nemesis 1]

1.2.2 Three-Byte Extended Prefix
All extended instructions can be encoded using a three-byte prefix. XOP instructions use only the three-byte prefix, but VEX-encoded instructions that comply with the constraints described in Section 1.2.3, “Two-Byte Extended Prefix” can also utilize a two-byte prefix. Figure 1-3 shows the format of the three-byte prefix

1.2.3 Two-Byte Extended Prefix
All extended instructions can be encoded using the three-byte prefix, but certain VEX-encoded instructions can also utilize a compact, two-byte prefix. XOP instructions do not use the two-byte prefix. The format of the two-byte prefix is shown in Figure 1-3.

game set and match.....

Your talking byte Intel is talking bit. This correlates to code length and AMD cannot go outside 256 bits That space is reserved to Intel future AVX instructions. But intel can legaelly go beyond 256 bits

 

[Outrage]

John said befor this post laid dorment That Intel had to pad the YMM in the upper half . and AMD wouldn't suffer from the delay that intel would suffer . Than I showed from intels PDF that Intel said it affected FMA . Yet you are attacking me . When I posted directly from Intels PDF. I took the Time to read Intels PDF although I type slow and badly I read remarkably fast .

John did't say that, he was quoting Pallavi Mehrotra from Intel, you should send a mail to that guy from intel and tell him he is wrong. Good luck with that.

 

[Outrage]

Your talking byte Intel is talking bit. This correlates to code length and AMD cannot go outside 256 bits That space is reserved to Intel future AVX instructions. But intel can legaelly go beyond 256 bits

So you finally agree that you where wrong the whole time. Thats great.

 

[jones377]

Your talking byte Intel is talking bit. This correlates to code length and AMD cannot go outside 256 bits That space is reserved to Intel future AVX instructions. But intel can legaelly go beyond 256 bits

Yup, those bits are reserved for future processors. When Intel specifies and extends AVX to 512-bit registers AMD will be free to implement those too, just like they have implemented AVX and will implement AVX2 eventually. What AMD cannot do is specify their own extension to 512-bit AVX using those reserved bits. Does this start to make sense to you now Nemesis?

 

[Nemesis 1]

Yea except the VEX prefix is inside every AVX instruction, which AMD implements. The documents, both AMD and Intel support this. The reason the XOP instructions uses the XOP prefix is because they are a left over from SSE5 proposed by AMD and then abandoned and transfered to AVX as XOP.

The bigger problem here is that you are unable to admit that you are wrong, unfortunately for us. Have you ever been wrong about anything in your life and admitted it Nemesis?

Hay I am not doubting you . But unless this paper says that XOP can replace the Prefix REX

with a single bit inside the XOP prefix as intel does your argument is mute.

 

[Outrage]

Hay I am not doubting you . But unless this paper says that XOP can replace the Prefix REX

with a single bit inside the XOP prefix as intel does your argument is mute.

Why would intel have a bit to replace xop with rex..... you should probably rethink your question and try one more time.

 

[Nemesis 1]

Yup, those bits are reserved for future processors. When Intel specifies and extends AVX to 512-bit registers AMD will be free to implement those too, just like they have implemented AVX and will implement AVX2 eventually. What AMD cannot do is specify their own extension to 512-bit AVX using those reserved bits. Does this start to make sense to you now Nemesis?

You just don't get it Inside intels VEXPREFIX are bits thar replace the entire Rex prefix done in bytes. Thats just an example That is instruction length . You show were XOP has bits inside the XOP prefix that replace the rexprefix and your onto something . Intel will expand AVX as they develop the bit encodes inside the vexprefix . Not until .

 

[jones377]

You just don't get it Inside intels VEXPREFIX are bits thar replace the entire Rex prefix done in bytes. Thats just an example That is instruction length . You show were XOP has bits inside the XOP prefix that replace the rexprefix and your onto something . Intel will expand AVX as they develop the bit encodes inside the vexprefix . Not until .

No, you got it all wrong. VEX replaces REX yes, but only in AVX. AMD cannot implement AVX without using the VEX prefix, impossible because all AVX instructions use AVX. Inside the VEX prefix are some bits that Intel has reserved for future use. Those are the ones you keep harping about. Intel doesn't use those right now either. But they will in the future when they extend AVX to 512 bit and 1024 bit.

They reserved those bits so that AMD cannot pre-empt Intel and extend their own non-compatible 512-bit extension to AVX. This is what reserved means. It doesn't mean they are Intel exclusive. it just means Intel reserves the right to use them in the future to further extend AVX. Once an instruction is defined by Intel, AMD is free to use it.

 

[Nemesis 1]

John did't say that, he was quoting Pallavi Mehrotra from Intel, you should send a mail to that guy from intel and tell him he is wrong. Good luck with that.

Hay don't play games with me . I know what John said and I went inside the Intel PDF and pulled exactly what was written . What John said is here for all to see . Its more what John didn't say . You clearly know what I am referring to. So stop the games OK a little honesty and integrity goes along way .

 

[Nemesis 1]

No, you got it all wrong. VEX replaces REX yes, but only in AVX. AMD cannot implement AVX without using the VEX prefix, impossible because all AVX instructions use AVX. Inside the VEX prefix are some bits that Intel has reserved for future use. Those are the ones you keep harping about. Intel doesn't use those right now either. But they will in the future when they extend AVX to 512 bit and 1024 bit.

They reserved those bits so that AMD cannot pre-empt Intel and extend their own non-compatible 512-bit extension to AVX. This is what reserved means. It doesn't mean they are Intel exclusive. it just means Intel reserves the right to use them in the future to further extend AVX. Once an instruction is defined by Intel, AMD is free to use it.

AMD does not have the compilers to do as you sugjest . Intel is not going to give AMD their jit compilers. AMD can only implement AVX with XOP . Vexprefix and AVX are not the same . oneis the instruction set the other is the Code . Inside intels byte code for vexprefix are bit code that replaces all that byte code . Here's what I am going to do . I will just go get the AVX white paper and lay this to rest.

 

[Outrage]

Hay don't play games with me . I know what John said and I went inside the Intel PDF and pulled exactly what was written . What John said is here for all to see . Its more what John didn't say . You clearly know what I am referring to. So stop the games OK a little honesty and integrity goes along way .

here is the post for everyone to see post 364

 

[garagisti]

This should work really...

http://www.xtremesystems.org/forums/showthread.php?265710-AMD-Zambezi-news-info-fans-!/page37

I don't know why the damned link didn't work... However, check the post number 917 on that page.... this is a guy with SR2 rig and eagerly waiting for BD's. I'm in the que alright.

 

[Nemesis 1]

here is the post for everyone to see post 364

And I had posted this befor John ever posted that , Its like I said its not like I am tring to decieve you . Read this and comprehind . Its not so much what John posted but what he didn't post .

256-bit VEX-encoded instruction and legacy 128-bit SIMD instructions has internal
state to manage the upper and lower halves of the YMM states. Functionally, VEXencoded
SIMD instructions can be intermixed with legacy SSE instructions (non-VEXencoded
SIMD instructions operating on XMM registers). However, there is a performance
impact with intermixing VEX-encoded SIMD instructions (AVX, FMA) and
Legacy SSE instructions that only operate on the XMM register state.
The general programming considerations to realize optimal performance are the
following:
• Minimize transition delays and partial register stalls with YMM registers accesses:
Intermixed 256-bit, 128-bit or scalar SIMD instructions that are encoded with
VEX prefixes have no transition delay due to internal state management.
Sequences of legacy SSE instructions (including SSE2, and subsequent
generations non-VEX-encoded SIMD extensions) that are not intermixed with
VEX-encoded SIMD instructions are not subject to transition delays.
• When an application must employ AVX and/or FMA, along with legacy SSE code,
it should minimize the number of transitions between VEX-encoded instructions
and legacy, non-VEX-encoded SSE code. Section 2.8.1 provides recommendation
for software to minimize the impact of transitions between VEX-encoded code
and legacy SSE code.
In addition to performance considerations, programmers should also be cognizant of
the implications of VEX-encoded AVX instructions with the expectations of system
software components that manage the processor state components enabled by
XCR0. For additional information see Section 4.1.9.1, “Vector Length Transition and


IDC I asked the wife to pull the AVX white paper and she agrees with you , Its a dead horse the debate was won long ago. Its a dead horse and in the end there will be weeping on the AMD side of the fence

 

[Idontcare]

IDC I asked the wife to pull the AVX white paper and she agrees with you , Its a dead horse the debate was won long ago. Its a dead horse and in the end there will be weeping on the AMD side of the fence

Well they can't do any worse than Via, and with their GPU IP I suspect they won't do any worse than NV. But yeah, the upside potential for continuing to ride the x86 pony may be rather limited. Time will tell.