Re: [oc] Non-stalling pipeline?

[Rudolf Usselmann <rudi@asics.ws>]

I'll answer both of your emails here, Ali.


On Saturday 30 March 2002 12:35 pm, you wrote:
> I found some stuff but not everything. I think when they say
> non-stalling pipeline they mean it only pertaining to the instruction
> fetcher.

I think this is all that matters anyway. As long as you continue
fetching instructions and executing them, thats all that matters.
They can't keep all 6 execution units busy anyway, as they are
only fetching 4 instructions each time. The real question is are
their compilers and/or reorder hardware  capable of always
issuing 4 instructions ? What is the true average utilization
that can be achieved running Solaris ?

> Instead of freezeing everything the pipeline is allowed to
> continue with nop's filling in the gaps until the instruction is
> fetched. I don't know if they stall the pipeline at all due to
> dependencies.

Well, thats kind of the same thing. You are right some of the
pipelines are basically fed with nops when they are idle.

I think in general what Sun is trying to say is that they can
almost(?)  always issue 4 instructions.

> Ali

On Saturday 30 March 2002 12:10 pm, you wrote:
>
> Well anyone have a sugestion on how it's done? I agree it's a flaw, but
> how is it done when you have 14 stages that makes for many possible
> dependencies and even with fowarding your bound to have one or two
> unless either you reorder the instructions and place nop's when you need
> to drop a clock cycle. But still with 14 stages and 4 way super scaler I
> would think the reorder buffer needs to be greater than 4*14. And I do
> not believe that sun is using out-of-order execution. If someone can
> point me to some research papers/examples on this it would be nice.

Reorder buffer and pipeline size are two different things. They should
be completely independent.

They don't say how big the reorder buffer is or even if they have
one (at least I didn't notice anything). However they do say they
have a 2Kb pre-fetch buffer. They also say that they do speculative
execution of branches. So that answers 99% of all pipeline stall
right there. When they executed a branch in to the wrong direction,
thy cancel the executed instruction (think of it as a "undo"). Which
makes me think they didn't really fix the problem, but pushed it in
to a different place. Depending on how good their branch prediction
algorithm is, they might have reduced the effective slow down when
a branch is taken depending on how may instructions they have
to cancel ...

> Ali

Cheers,
rudi


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml