Jouni Osmala (josmala@cc.hut.fi) on 9/19/09 wrote:
---------------------------
>AM (myname4rwt@jee.male) on 9/19/09 wrote:
>---------------------------
>>As a small addendum, consider the e200 family -- single-issue, in-order cores, except
>>for z7. Only the simplest/lightest cores of the family have 4-stage pipeline with
>>2-cycle IF-EX distance (as in 603), others have longer pipelines (10 stages in z7).
>
>Hennessey & Patterson
>Computer Organization & Design.
>Think where you add register renamers & logic to chooce which instruction goes
>next to its pipeline. The only way for you to actually understand the underlying
>issue is to learn how to design inorder & OoO Pipele. Start reading it, and you
>understand eventually what I claimed is true. It adds time between IF->EX if you
>abstract time as pipeline stages you should acknowledge the clockspeed effect on
>time, then start thinking about alpha, for its time.
>
>The 4 stage pipeline is standard risc pipeline,

http://en.wikipedia.org/wiki/Classic_RISC_pipeline

just in case your memory is failing that much.

the OoO logic could be added to it without adding, pipeline stages,
>but at that point you add TIME by delay.
>BUT still you would have to deal with a problem of having register renamer and
>THEN have to load registers. And need for instruction selection logic. If you understand
>what register renamer does you would understand that you cannot do that parallel to register fetch.
>
>The problem you have is that at this level you have abstracted a lot. You look
>1990's designs in a way that liming factor for clockspeed would be same as in 2000.

I don't think I do. Anyway, feel free to compare 90s with 90s -- this is what I asked you in the homework.

>Its not just power, its gate delays. Nowadays gatedelays are not the dominant factor,
>and you need to increase pipeline length just to keep wiredelays from dominating everything.
>You cannot compare things many processgenerations apart without acknowledging the difference.
>
>MY question is this, how can you put register renaming parallel to register access?
>I couldn't find a way, thats all thats is needed for increase the delay form IF to EX.

IF-EX is not even what I called you on, although I'm *very* curious if you can find a -- presumably -- chip built for performance that beats a low-power OoO chip in terms of IF-EX delay. Go for it Jouni! See if you can back your point with some facts in a challenge that's obviously made much easier for you than it could be!

And apart from IF-EX, you wrote:
"... However, with equal clock generation hardware inorder system would clock higher."

And what I asked was:
"More work (+ die space) -- yes, indeed, but the last statement is not obvious at all. Why?

Which part of OoO stuff imposes a hard limitation on clock rate, hittable by an in-order chip, yet unhittabble by an ooo chip?"

http://realworldtech.com/forums/index.cfm?action=detail&id=102313&threadid=101547&roomid=2

So why don't you defend the statement I called into question?

>Also just another SINGLE number on the z7. WHERE'S THE PIPELBetter than that, your
>example doesn't even show wether the number you just found somewhere, includes cache
>L1D accesstime OR mainmemory accesstime or what everINE DIAGRAM? Where's its spend!
>for those stages, and process generation & clockspeed & voltage. Also I'm pretty
>sure its not made in same process as powerpc 603.

Did I imply anything wrt clock rate vs 603 or other designs? No. I only brought this example up as these cores are all in-order, most of them single-issue -- as your argument from the very beginning revolved around OoOE.

And as for 603, feel free to consider 0.35 and 0.28 um process it was fabbed on.

>Thing is that wiredelays have gotten exponenetially worse relative to transistor
>delays each generation from that period so you start to need more and more buffers
>to keep clockspeed up for given voltage and cache access times go worse. It should
>hurt more for designs which need more area for something like OoO logic to run those signals over.

Of course I do agree that physically larger core, w/o knowing anything else, is likely to suffer more from signal-propagation delays. It was my own argument, in case you missed it.

The thing is, it's ridiculous to connect this to OoO. Doing so is about as smart as saying how caches take away precious die space and how larger caches hurt access latency.

Like my example? Feel free to add it to your list of CPU baddies alongside OoOE.