hcl64 (mario.smarq@gmail.com) on 4/28/12 wrote:
---------------------------
>Paul A. Clayton (paaronclayton@gmail.com) on 4/20/12 wrote:
>---------------------------
[snip]
>A 6 wide issue processor for x86 is simply a pipe dream...
>until there will be ways to considerably break the "strong
>dependency model" of x86 it will be out of reach.

Support for 6 wide execution is not so much physically
impractical as economically impractical. x86 is not in a
performance at any cost market, and most of the code run on
x86 is not high-ILP code.

It is not clear what you mean by "strong dependency
model". A quick google found a use of that by you in
another forum where you seem to refer to memory
dependency checking. This is not a particularly x86
issue. (Yes, with only 16 GPRs x86 will have more
memory activity, but this is not a huge barrier and having
fewer GPRs helps in renaming and load-op instructions
communicate single-use temporaries 'registers'.)

OoO can expose some ILP and wide execution can be useful
at times after a dependency on a long latency operation is
resolved (wide execution could also be helpful in branch
misprediction recovery with few checkpoints); but the
cost-benefit ratio seems to favor more moderate width.

>4 may be already too much (BD is a false 4 wide issue),

The value of 4 wide depends on design budget and design
goals. For Intel, high single-thread performance is more
practical (e.g., higher volume allowing higher absolute
design costs and more binning) and perhaps more important
than for AMD, and Intel seems committed to SMT (which
benefits from 'excessive' width).

Width is also somewhat flexible in meaning given the
potential to fuse operations, and cascaded ALUs could
further confuse the matter.

[snip]
>>As discussed here earlier, the motive seems to have been
>>to allow substantial sharing between threads in a high
>>frequency design without the data cache issues that the
>>early Pentium4 SMT suffered.

My post in an earlier thread is here:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=123280&threadid=123055&roomid=2

That post refers to a comp.arch post by Andy Glew--who
was actually at AMD during part of the development of BD.

>As above the only things that shares threads in BD are the
>FlexFPU and the L2..

A very quick estimate based on the Orochi die image might
give 75% of a module as shared (excluding area marked as
L2, which would mean about 12% for each integer core).
Even a 50% area sharing would be significant.

>not even a remote resemblance with P4,

BD was clearly targeting higher frequency (like P4) and
used a relatively small (especially for AMD) Dcache (like
P4).