>>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,

I told you to look at THE book that is used to teach computer design.
That is not I deny is possible, but THAT cost clockspeed if you don't add the extra stage. The basic idea is simple ANY logic that increases number of gate delays between instruction fetch and execution either cost cycle time OR pipeline stage. And you haven't shown any way to design OoO pipeline without affecting the distance. The inorder pipeline can do parallel decode and register fetch, in classic risc parallerising, it requires checking RW dependency to previous instruction in same cycle, which can be done mostly parallel to register fetch & decode, and only one "and" gate required after that.

Now OoO pipeline, register rename is done before register fetch.
Also Other dependencies are
decode->movetoReservationstation->issue from reservation station. These low level things couldn't done parallel. And just are serial work, that isn't split on 603 to multiple stages which limit its clockspeed.
603 the limiting problem isn't power its gate delays, so you couln't just assume it could clock higher with that design without changing design. There's reason why apple got stuck so low clockspeed while having low power when amd and intel went to 1 ghz and consumed more power. (G4 also was limited by gate delays)


>>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.

Z7 vs 603.
I don't take home work from you.

>>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!


You where asking about strawman of having less than standard risc pipeline stages. What I'm all about telling its about TIME. There's plenty of reasons why inorder alpha EV5 clocked 4 times higher than 603 at same process.
That means EVERY pipeline stages take one quarter of a time of 603. So basicly EV5 pipeline does take 1/2 of time of an 603 before the execution stage.

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

In original context it simply means, if OoO chip had electrical design improvements same improvements could be applied to inorder design also. There was either
A),B) OR C) If C chosen, then inorder design with C) is faster than original inorder design and higher than the resulting OoO chip with C.
If however C&A are happening then both can clock as high, I didn't mention that since it was just a trivially deductible fact.

>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?

Atleast that claim you put the link to is about potential three way trade off. Either increase pipeline lenth OR reduce clockspeed compare to similar inorder design, OR do other electrical low level improvements to compensate the extra logic delay caused by OoO logic compared to previous design.

If the designers choose the THIRD option, then you could do same for inorder pipeline and clock higher. So third option is irrelevant other than showing that there is other methods to deal with extra logic delay than those two.


>>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.

Z7 is process generations apart, you looked about total pipeline length in isolation without looking what is included in the pipeline length. nada, what you brought about Z7 is irrelevant to our discussion without more details. And the ONLY figure you mention is irrelevant as is, and what you would compare it against? 603 is not reasonable since they are too many process.
Z7 is pipeline length is A datapoint. As such you need to show
A) How many stages are before ex stage.
B) How many stages for cache access?
C) Does it have scewed pipeline aka. LOAD pipeline before execution pipeline.

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

It was manufactured 0.5 and got 75mhz there and EV5 got 300mhz.

>>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.

Actually OoO logic makes it larger, and where that logic resides? Just between if &exe. If you want Z7 as example you should put and OoO core of similar generation as counter example. I mentioned the cache accesstimes because thats really important for the Z7 and NOT important on 603 generation, and the number you gave for z7 doesn't say weather it has TWO cache accesstimes there or ONE. Anyway it has it in total pipeline lenth.