Sandy Bridge

Chipper posted a link to Intel's IDF presentations (doesn't work for me right now but others were successful ) in this SemiAccurate forum thread. The thread already contains some extracted information. For more details and the slides there is an article at AnandTech. It looks like many rumours (e.g. 1500 µOp buffer which is no trace cache, but a direct mapped i$), clock ranges etc were true. In his article Anand mentioned the reusing of integer SIMD datapaths for extending the available resources to 256 bit for processing AVX FP instructions.

This sounds interesting and explains the only light area increase of the FPU after adding AVX. Looking at the execution data paths, it is obvious that similar integer SIMD logic (e.g. MUL sitting next to FMUL) is available in the 128bit datapath in the middle of the schematic. For example it is possible to use parts of an adder to calculate narrower additions and the same is true for multipliers and many ALU ops. So it's possible that a Sandy Bridge SIMD unit uses integer add and mul logic to do some parts of FP calculations (working on the mantissa bits). Intel's patent no. 7,389,406 (by Intel's Israel team) might come into play here, but I have to read it in full to see, if it fits. A rather similar one is no. 7,457,938 by their U.S. teams.

Other nice features include a "borrowing" Turbo boost, which uses a "saved" TDP budget (accumulated during idle times) to boost cores while going over the TDP limit until the budget has been used up.

According to SemiAccurate, Intel want's to ship Ivy Bridge (22nm tick of Sandy Bridge) in the second half of 2011, which might be the same time frame when Bulldozer will arrive.

3DNow!

After AMD made their decision public that future MPUs won't support 3DNow! anymore, many concluded that this will be the case for Bulldozer as well. But I found this:

+  { "CPU_BDVER1_FLAGS",
"Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|Cpu686|CpuSYSCALL|CpuRdtscp| Cpu387|Cpu687|CpuFISTTP|CpuMMX|Cpu3dnow|Cpu3dnowA| CpuSSE|CpuSSE2|CpuSSE3|CpuSSE4a|CpuABM| CpuLM|CpuFMA4|CpuXOP|CpuLWP" },

(Source: http://cygwin.ru/ml/binutils/2010-01/msg00576/7007_bdver1.diff, referring to opcodes/i386-gen.c)

This could either be a copy paste error or BD will still support those extensions. But there are other candidates for dropping it like a BD Version 2 (which might come sooner than later since someone, who should know it better, hinted that we won't have to wait 5 years for it). Also Bobcat is a candidate since 3DNow! might just have been left out for die area and power saving reasons.

There are also some changes in AMD's manuals (thanks, Alex):

CPUID doc 25481.pdf now contains some CPUID bits for Lightweight Profiling (LWP), 16bit FP conversion (F16C, similar to  CVT16), an Effective Frequency Interface and more. See also a bug report (more a feature request) at opensolaris.org:

Description
With introduction of core performance boost (see CR6932922) in family 15h processors (as well as 12h and 14h) it may be difficult to know core's frequency. Effective Frequency Interface allows kernel to find out average frequency of a core over a period of time.

There also is an AM3 doc: 40523.pdf

And there is more from AMD:

John Fruehe posted his second and third round of the 20 questions blog. There also is a video interview with him at the Inquirer.

Simon Solotko demonstrates the Zacate Fusion processor here. A video showing more of the 3D action can be watched here.

InsideHW interviewed Leslie Sobon about the upcoming Fusion APUs. A quote:

And let me tell you one thing about Llano, the reaction of all our partners after seeing the demo was, in one word, “whoa”.

Clock frequency numbers and other specs of embedded Ontario processors ("eOntario") appeared. It is possible, that the frequencies and TDPs will be the same for the consumer variants. So the highest clock frequeny is 1.6GHz, which might be the same for the BOINCed engineering samples.

Andy Glew posted quotes of a Microprocessor Report article about Bulldozer on comp.arch. In another thread he discusses the position of Bulldozer's renamer.

And someone seemingly erroneously posted SPEC2k results of Atom using GCC:
http://gcc.gnu.org/ml/gcc/2010-09/msg00000.html