Re: [Gems-users] squashing the pipeline in opal

[Gedare Bloom <gedare@xxxxxxxxxxxxxx>]

It seems you might want to try to stall the thread's fetching instead
of squashing in-flight instructions.  Squashing is mainly useful for
undoing speculative work, and I think the dynamic instructions
continue to exist for awhile after squash is called.  If the
long-latency event is detected quickly, then stalling may be
sufficient to save resources. It depends on how much is fetched before
the stall starts.

Stalling fetch isn't too difficult in pseq (for single thread I have
done it before), you can create some condition and use it to prevent
the Fetch/Decode, while continuing to Execute and Tick. I don't see
why it shouldn't work in SMT, you just need to add conditions when
looping over the array of processors to single out the thread of
interest.  Eventually, stalling fetch should drain the iwindow of
instructions from the stalling thread.  You might also need to add
some checks to prevent seg faulting on an empty iwindow.

If you still need to squash the instructions, you might want to look
at how the pipeline is drained in pseq's retireInstruction function.
I'm not sure if squashes occur in fetch order when undoing a
misspeculation, but maybe there is some problem with the order in
which you are squashing instructions.  Alternately, there could be
some problem with the stage of the instruction when you call squash,
or the type of instruction might be causing issues (e.g. memory and
control squashes).

-Gedare

On Tue, Feb 15, 2011 at 2:12 AM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:
> I know there aren't too many people that are that familiar with opal anymore, but I figured it can't hurt to ask.  Basically I'm trying to add a new condition that will cause a pipeline squash within opal, this is primarily for use within an SMT processor.
>
> Imagine you have an SMT processor, and you have an instruction that knows it's going to be a long latency event (hundreds of cycles), what I want to do here is squash the pipeline for future instructions after this one, and prevent opal from fetching from this thread again until the request has been serviced.
>
> The point of this is to free up resources in the instruction window that would be better used by other threads running on the processor.  I have attempted to set this up in a new routine in pseq.C called SquashInstruction, however this is causing all sorts of errors in my code.  Most notably, after calling Squash, the instruction i wanted to cause the squash event is still in the instruction window.
>
> My code for this method is as follows:
>
> void pseq_t::SquashInstruction(dynamic_inst_t *d)
> {
>
>  partialSquash(d->getWindowIndex(), d->getCheckpointFetchAt(),
>                (enum i_opcode) d->getStaticInst()->getOpcode(), d->getProc(), false);
>  d->Squash();
> }
>
> However not long (10s or 100s of cycles) after this is called the simulator will give an error or crashes depending on how I do things (i've tried a few permutations of this basic approach).  Does anyone know if there's anything else that needs to be set to force a squash in the instruction window?
>
> If anyone is familiar with squashing instructions in opal (or knows someone who might be familiar with this), please let me know.
>
> thanks,
> Phil
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>