Intreger SSE operation (on integer operands kept in SSE registers) go through ALU, floating point SSE dispatched to FPU.
There is nothing more to talk about...
Printable View
Intreger SSE operation (on integer operands kept in SSE registers) go through ALU, floating point SSE dispatched to FPU.
There is nothing more to talk about...
Maybe but we don't need YOUR dose of K10 and your posts are getting boring actually.Quote:
Originally Posted by madcho
Sorry, i got absolutely no interest for virtualization and can't even see why you felt like quoting me.Quote:
Originally Posted by nn_step
excuse me as I glare at you for a couple minutes until you realize how retarded you sound right nowQuote:
Originally Posted by SEA
at least tell him why he's wrong when you criticize like that, same for others..Quote:
Originally Posted by nn_step
A. you would not only educate the criticized, but also others, like me, who are interested in knowing and would like an enthusiasts explanation, not 200 pages of technical wording
B. you wouldn't diminish the thread by adding to the fodder that are posts like these
somehow I think nn knows what he is talking about since he is writing an OS...
in my post, read AQuote:
Originally Posted by eXceededgoku
nn_step
Please make your point clear.
What sounded wrong for you?
Existance of integer SSE?
Or that integer SSE being processed by ALU?
SSE is by nature shares the floating point logic for all calculations because that is the design of Katmai by intel set that standard. Which shared the same hardware, however later designs (sse2) used separate hardware for SSE however they still continue to share the same registers.Quote:
Originally Posted by SEA
SSE is SIMD (aka Single Instruction, Multiple Data)
Now SIMD such as Altivec, is an entirely separate chunk of silicon for SIMD functionality. You can not use SISD (single instruction, single data; think ALU) for SIMD work without a serious performance hit. Intel and AMD nor any other processor company would allow such work to be done, knowing that it would seriously effect performance in a negative way.
nn_step
uffff....
Yes, thank you for bringing your knowlege, but do not hurry...
Let's talk about, say, this instruction - PMAXUB:
Integer Intrinsics Using Streaming SIMD Extensions from
MSDN, C++ reference, Integer Intrinsics Using Streaming SIMD Extensions
PMAXUB - Computes the maximum, unsigned
Of course we can pick any other instruction from this list to discuss...
( Or, we can choose another list - there are more)
all SIMD instructions, regardless of if they are integer or floating point are processed (in all modern processors) in the designated SIMD hardware.Quote:
Originally Posted by SEA
But you must remember floating point and SIMD logic are made up of ALUs and dedicated hardware.
nn_step
Ok, we've got some progress
So, now you agree that Integer SSE exists.
Now we go to part2. I'll be back soon with links ;)
P.S.
i hope now you don't do this anymore:
excuse me as I glare at you for a couple minutes until you realize how retarded you sound right now
ok. So Integer SSE exists.
Now, let's consider this picture. I'm sure this will make clear second part of my statement:
http://www.pureoverclock.com/images/review/k8l_fpu.gif
As you can see on top of picture it says about path of SSE instructions. And you see there ALU and FPU in that path, do you?
http://www.intel.com/cd/ids/develope.../eng/66753.htm
http://www.amd.com/us-en/assets/cont...docs/24592.pdf
fine, please notice that the timing information for the SSE and floating point calculations have the exact same number of stages. While Integer math (ALU) as a much lower number?
Also notice that they BOTH inform you NOT to attempt to Schedule Floating point and Vector (SSE) math at the same clock cycles. (because those units share the same registers)
and to completely refute your comments using die shots
http://www.chip-architect.com/news/2...4bit_Core.html
or more specifically notice how ALL SSE units are in the Floating point not with the Integer
http://www.chip-architect.com/news/O..._1600x1200.jpg
for a closer look at the floating point/SSE
http://www.chip-architect.com/news/O...atPnt_Core.jpg
and now Integer
http://www.chip-architect.com/news/O...teger_Core.jpg
notice the completely lack of SSE mentioned in the integer unit?
Yep,i think nn is correct here.Nothing against SEA of course...
If they did not mention that integer SSE does not go to ALU - it does not prove anything... You might just bring wrogn pictures.
But picture i provided above has direct statement.
Also, can you please reduce your images, it won't help you.
I will provide more info later.
Not to sound rude to either of you guys, but I' am guessing that rather few of us care what you are arguing about. If you want to discuss it farther I think all of us would appreciate it if it was done through private messaging. Not that this isn't interesting(vomit), it's just that it's starting to drift off topic and is cluttering the thread with pictures that are not of hot woman.
you are arguing with official AMD Die shots and using conjecture to attempt to argue with proven facts. I'm not saying that in theory you can't do SIMD in the ALU but I am saying doing that will seriously effect performance (we are talking a few orders of magnitude here)Quote:
Originally Posted by SEA
and using your exact same argument, you must be retarded because you didn't explicitly say that you aren't. I'm done with this thread, post what ever you feel like but I am done trying to convince another noob that they are mistaken.
Brent,what about this one :
http://www.xtremesystems.org/forums/...&postcount=248
:D
Oh no no :D,you agreed with SEA's argument but then you said nn is correct :confused: .You can't have it both way.Either the SSE integer goes to the ALU or they dont.Read what nn said before.Quote:
Originally Posted by brentpresley
BTW nn used Hans' article.Isn't that guy smtng? The whole K8 Hammer in pipieline pieces :)
I think the confusion was made in the part when decoders parse the instruction further to the exec. units.
They were arguing about decoded instructions.
I don't mean to talk down to you guys...
But CPU stands for Central Processing Unit. It's the box under the desk that is the "brain" of the computer. The part you look at is called the "monitor."
But seriously, I've seen people give old farts instructions about how to use a PC, and this is in lesson 1. I guess actually cracking the case open and showing them the cpu would probably be too advanced, so they just call the whole box the cpu.
Thanks for your time.
Ryan
I don't mind the conversation and its highly educational in some senses. :)Quote:
Originally Posted by Nanometer
Maybe they should argue while posting pictures of hot woman:D
^^ I thought "CPU" was short for "computer"...:p:
Right, we were talking about uOps execution units.Quote:
Originally Posted by informal
nn_step
After considering things i agreed with you.
SSE FPU easily can do same operations - comparisons, shifts (they have to be implemented in SSE FPU anyway for other arithmetic operations).
Additionally, it is easier to implement hardware. I mean, SSE registers connected only to SSE processing units, and it saves from 3 x 128 bites lines going to other ALU or somewhere else.