Page 1 of 1
SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 6:56 pm
by JackScott
I've been working on a
IA32 Architecture Family page, and it all seemed very simple (relatively). There was MMX, there was SSE, SSE2, etc. Now I've started putting in information on AMD chips, and I've got very confused.
MMX was created by Intel, and is supported properly on all modern AMD chips.
3DNow! was created by AMD, as something 'better' than MMX, and only exists on AMD chips.
SSE(2,3,4) was created by Intel as a response to 3DNow!, and is supported by Intel chips (and AMD chips?)
AMD also created some SSE specs, incompatible with the Intel ones.
Have I got all this correct, or am I being more confused than I need to be?
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:25 pm
by Love4Boobies
SSE is the same for both Intel and AMD CPUs. Intel didn't come up with all the SSE specs, though. For instance SSE 5 (which isn't yet implemented in any CPU - AFAIK the latest implemented is SSE 4.2) was developed by AMD and you can find the spec on their web site. I also have a question but have failed in finding an answer
Do AMD CPUs support MMX or just 3DNow! ? My guess is that they probably do.
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:39 pm
by JackScott
I'm moderately sure that MMX is supported on all the AMD chips K6 onwards. That's what I could discern from Wikipedia, anyway.
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:40 pm
by JohnnyTheDon
If I remember correctly MMX, SSE, and SSE2 are required for all x86-64 chips.
Also, about the AMD64 thing on that page, there are now processors cheaper than $180 that are 64-bit:
AMD Athlon 64 X2 5200 Brisbane 2.7GHz
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:42 pm
by JackScott
The bit with pricing was written ages ago, so that'd be in need of an update (or removal, which will take away the problem of updating it in future). It also assumes US dollars and Euros are about even... *chuckles to self*
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:53 pm
by Love4Boobies
Ok, I want to make some corrections to my previous post:
- Some Intel CPUs support only up to SSE 4.1. SSE 4.1 isn't a superset of AMD's SSE 4 but a subset of it.
- SSE 5 is not a superset of SSE 4 but a competitor to it.
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 7:56 pm
by JackScott
Love4Boobies wrote:SSE 5 is not a superset of SSE 4 but a competitor to it.
And this, my friends, is why the world is doomed. What sort of consumer is going to understand that?
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 9:00 pm
by whowhatwhere
JackScott wrote:Love4Boobies wrote:SSE 5 is not a superset of SSE 4 but a competitor to it.
And this, my friends, is why the world is doomed. What sort of consumer is going to understand that?
Hello.
Would you like to join the CISChate Club?
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 10:06 pm
by JohnnyTheDon
/agree
Imagine what would've happened if AMD hadn't made AMD64. Instead of extending an extension dating back to the 8086, we would probably all be using the RISC IA64 (which seems like a fairly nice and forward thinking architecture).
Damn AMD for wanting to save their company >:(
Re: SSE, 3DNow!, and a rather large mess
Posted: Sat Apr 25, 2009 10:58 pm
by Love4Boobies
JohnnyTheDon wrote:/agree
Imagine what would've happened if AMD hadn't made AMD64. Instead of extending an extension dating back to the 8086, we would probably all be using the RISC IA64 (which seems like a fairly nice and forward thinking architecture).
Damn AMD for wanting to save their company >:(
Actually, the Itanium isn't RISC but VLIW. From what I read about it it seems pretty cool but I heard there are some disadvantages (as well as advantages, of course) in using it. I'm not sure what these are, however.
Re: SSE, 3DNow!, and a rather large mess
Posted: Sun Apr 26, 2009 3:17 pm
by earlz
The VLIW part is what I was interested in...
Imaging leaving out-of-order execution optimizations to the compiler(which knows what it's doing) rather than the CPU so precious CPU space could be spent for more cache and such.