SSE3 Technology In Intel Prescott

topmo writes "X-bit labs has posted an article called 'SSE Technology in New Intel Prescott Processors.' In this detailed technology coverage they talking about the SSE (SSE3?) technology implemented in future Intel Prescott processors, its exciting history, its peculiarities and advantages offered to the software developers. Also they compare the cons and pros of the new PNI (Prescott New Instructions) with AMD x86-64."

Comments

Re:the x86 is at a dead end

[Anonymous Coward]

If x86 disgusts you so badly, why would you even consider an Opteron?

Maybe because it's fast, cheap, and runs all your software? (Because after all, YOUR software is important, but my software is 20 year old backward compatible crap.)

Face it, people like yourself is the reason that x86 is on top. Look in the mirror and see the enemy.

Re:the x86 is at a dead end

[OldMiner]

I agree with the OP that the x86 architecture is probably limited by it's high degree of backward compatibility. I don't have technical facts to back this up, but I think common-sense would agree with me here.

Well, yes and no. How about I quote an article that vaguely touches on the matter? Here's a random article that came up when I searched for "microinstructions x86". It somewhat explains the issues (though the author doesn't seem to understand that floating point registers, MMX registers, and SSE registers are all general purpose registers for most purposes).

Ah, but my point. The x86 is natively CISC (Complex Instruciton Set Computer) which means instructions have variable length and variable arguments. (Of course, SSE and MMX are both SIMD and have instructions varrying from 2 to 5 bytes long, so they're working against the whole RISC idea, but they've got their own special units.) Meanwhile, the SPARC is RISC based. In short, it's easier to make a RISC processor run faster. But that might not matter so much.

x86 implementation of the present day is essentially a RISC processor on the back end. The native CISC instructions are transformed into micro-instructions. This transformation is done in a decoder. So long as that transformation can be done quickly and the micro-instructions well pipelined, the decoder unit shouldn't be too much of a killer.

Having said that, it's worth mentioning some of the strange things that the decoder has to dedicate silicon to. Some trouble instructions are problematic in more than one way, as noted previously with plex86, PUSHF which pushes the current CPU flags (e.g. interrupt flag (enabled/disabled), zero flag (last comparison equal/last sub result in a zero)) onto the stack is problematic. Then there are others which are just a bad idea. PUSHA is an old instruction which pushes all of the 386 general purpose registers on to the stack (including (E)SP, even though it's ignored when POPA is called). These instructions are those sort of useless instructions which came from the philosophy that computers should, on the lower level, start to emulate the higher level languages they're normally programmed in. That idea didn't pan out, especially as RISC became clearly superior. Another similar strangeness is found in XLATB which I haven't seen used in my natural life by a human nor a compiler, but is still supported in modern CPUs. That's not even to get into BCD instructions...

As it stands, though, last I checked what most hurt computer performance in real situations are cache misses and branch mispredictions. I have seen HP make a processor that was completely backwards incompatible that solved this problem. That is, it forced you to recompile all of your old code. It packed instructions around every branch which indicated the full length of both paths. Then both paths could be evaluated at a low cost, and the results of the untaken path thrown away. Other similar things were done to increase the success of cache prefetch and whatnot. Server only, of course -- no one wants a non-backwards compatible processor on their desktop.

But, back to the article which is about new instructions which will improve some processing intensive applications. However, the article notes, problems with branch misprediction are not solved in the new Intel chip. The processor will be clocked faster (and hence, so will the cache) so the problem may be a bit less noticable.

But therein is the

Re:the x86 is at a dead end

[OldMiner]

The last time there was a major instruction set update was the Pentium Pro

Come again? I don't see where this statement is justified. IIRC, the Pentium Pro's significant additions were merely conditional moves, floating points compares whose result was put in the CPU flags, and fast system call instructions. Useful to a degree, but nothing revolutionary. Meanwhile, MMX and SSE2 both introduced about the same number of instructions which could potentially cause much larger increase in processor performance. Near as I can tell, this addition is no more or less big than any of the other recent additions (MMX, SSE, SSE2).

And, as a matter of fact, the last large instruction set update would then have to be 286->386 when we gained 32-bit, protected mode, many new instructions, and several new forms of old instructions -- and even then, the protected mode features in the 386 already existed in the 286 for the most part.

Prescott?

[Spudley]

Hmmm.... so Intel are naming their new processor after a British politician who's most noticable feature is that he's an overwight bully.

I wonder if they'll spot the irony in that?