AMD Previews New Processor Extensions

An anonymous reader writes "It has been all over the news today: AMD announced the first of its Extensions for Software Parallelism, a series of x86 extensions to make parallel programming easier. The first are the so-called 'lightweight profiling extensions.' They would give software access to information about cache misses and retired instructions so data structures can be optimized for better performance. The specification is here (PDF). These extensions have a much wider applicability than just parallel programming — they could be used to accelerate Java, .Net, and dynamic optimizers." AMD gave no timeframe for when these proposed extensions would show up in silicon.

Comments

Just performance counters?

[Erich]

Looks like there isn't a whole lot there that you couldn't get using existing performance counters and a tool like oprofile....

Re:Just performance counters?

[imgod2u]

Looking at the PDF, it supposedly gathers profile data in the background (in local caches on the chip itself) and dumps periodically depending on the OS/application settings. This allows it to profile on-the-fly with very little impact on application performance.

The application can then gather the information, which is stored in its address space, and do with it what it will (optimize on-the-fly).

Of particular interest is that the OS can allow the profile information to be dumped to the address space of other threads/processes as well as the one that the data is collected on. The OS controls the switching of the cached profile information during a context switch.

This is both cool (in that a secondary core/thread can help optimize the first) and scary (one thread getting access to another's instruction address information). I predict there will be exactly 42 Windows patches released 3.734 days after the service pack that allows Windows to take advantage of this feature because of security reasons.

Re:And so it goes on...

[edwdig]

There's very little difference between the instructions in the different modes. The memory management unit is where most of the differences are. Properly written 16 bit real mode code will still run in 16 bit protected mode. The only difference is how the segment portion of the pointer in interpreted.

As for 16 bit vs 32 bit modes. The instructions are mostly the same. A code segment is specified as being either 16 or 32 bit. That size is the default data sized used by instructions within that segment. There is a "size override" prefix, which if found immediately before an instruction, tells the CPU that the following instruction should use the opposite of default size.

I don't remember the specifics, but 64 bit mode just continues along with the same ideas. There aren't many changes from 32 bit code to 64 bit.

Re:I wish AMD and Intel teamed up for once

[Vellmont]

and did away with the aging x86 instruction set and came up with something new.

They did, at least with the FP (floating point) instructions. FP instructions were based on this awful stack architecture, and it's gone away with all the SSE and 64 bit extensions.

The x86 instruction set has evolved greatly over time, and will continue to evolve. Why replace it entirely from scratch? Who's to say that an entirely new instruction set won't have a whole new host of problems?

Re:Will Intel Adopt These Instructions?

[The Real Nem]

EM64T?

Re:I wish AMD and Intel teamed up for once

[Chris Burke]

I believe the 486 was the last CPU to run x86 instructions natively.

Close, it was the original Pentium. The Pentium Pro -- which despite the name which just made it sound like a minor improvement to the Pentium for business/servers was actually a completely new architecture -- is where they introduced the CISC->RISC conversion. This was in part to make it feasible to have out-of-order execution which many said CISC processors would never have. Turns out they were both right and wrong.

So let's stick with x86 for now, since the gains you foresee are either non-existent or tiny and are never, ever going to outweigh the drawbacks.

As much as I hate x86 from an aesthetic point of view, I must agree with you here.

You can get the x86/EMT64 documentation from intel

[Gazzonyx]

If you root around Intel's site a bit, you can get the developer manuals for asm on their chips; I think there's like 5 of them @ 300 pages+ each. It's all the documentation, I think only 1 book is the actual language specs. Anyways, if you ask them nicely via email, they'll send the manuals to you for free. I got mine in under a week from when I emailed them. They even pay shipping.

Also, I know from asm on SPARC that many op codes are really just variations of other ops (and/or pseudo ops). For instance, (I'm not sure of the x86 equivalent) .mul is a pseudo op for sll (shift left logical), IIRC. And almost every op has a data type specific variation (byte, half, word, double, etc), on top of that.

Re:I wish AMD and Intel teamed up for once

[x2A]

So what we need really is a "native" x86 compiler, say, from Intel, that would maybe outperform the multi-platform GCC compiler... an Intel C/C++ Compiler, or 'ICC' we could call it... maybe...

Oh who am I kidding, that could never happen.

Re:I wish AMD and Intel teamed up for once

[wirelessbuzzers]

Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do...

What's not to like? To start with, the complexity makes it a total pain in the ass to write kernels, compilers, runtime systems, analyses, debuggers and verifiers for x86. On top of that, it costs lots of engineering time, silicon and power to implement all those microcode crackers and fancy superscalar optimizations; this is why x86 can't hold a candle to ARM in the embedded world.

But maybe you meant missing instructions? No load-linked/store conditional or bus snooping. No double (or even 1.5) compare-and-swap. No hardware transactional memory support. Those three make it pretty hard to write fast concurrent code. And streaming operations are improving, but could be much better; there's a reasonable chance that cache coherency will soon be too expensive for practical use.

Maybe you're interested in single-threaded, native code performance; this is, after all, what x86 traditionally shines at. Here you'll find the lack of 3-register instructions to be a performance problem, even if the chip reduces this burden. There's no shuffle (like Altivec, although something like that is coming in Penryn, I think?), finite-field or bit twiddling operations, or conditional operations (a la ARM).

So yeah. There are a lot of things that the x86 instruction set could do better. I don't expect it to do them all, but there are certainly a lot of reasons to change it.

Jombeewoof, get off the Internet.

[Anonymous Coward]

Jombeewoof is a bastard who thinks the world owes him a living. http://slashdot.org/comments.pl?sid=267807&cid=202 07637 Jombeewoof tried to destroy an Internet Service Provider in Massachusetts by expecting large bandwidth without paying anything. Educated alone doesn't pay the bills. Jombeewoof is not worth your mod points and is a MySpace loser. Jombeewoof, give up, get off the Internet. The TrollGoons won't leave you alone.