> On May 12, 2015, 10:09 p.m., Jason Power wrote:
> > I'm going to echo what Nilay has said in a other reviews: Could you give an
> > example of how this is used? Say, an example getNextState() function. I'm
> > having a hard time visualizing how this is supposed to work in a protocol.
>
> Brad Beckmann wrote:
> The patch description shows how the feature is used. The burden cannot
> be to provide a public example for every new feature introduced in SLICC.
> That hasn't been the bar in the past and it will cause us to keep a lot of
> useful utility patches internal and our patch queues will continue to grow.
Hi Jason,
As mentioned in the comments, this patch allows a machine to collapse states
that differ only in the next state
transition. An example getNextState() function is given below:
State getNextState(Address address) {
TBE tbe := TBEs[address];
assert(is_valid(tbe));
return tbe.NextState;
}
I will try to give a simplified example so that the reviewers will be able to
understand the utility of this patch.
Suppose the machine is in state:INVALID_XXX. Also assume that the machine can
move to state:EXCLUSIVE or state:SHARED depending on the response it gets from
the directory/lower-level caches. However, before it moves to any of these
final state, assume that it has to wait for acknowledgements from its peer
caches. So, without the suppport of this patch, the slicc code will look as
follows:
transition(INVALID_XXX, ResponseX, INVALID_EXCLUSIVE){
do_something;
}
transition(INVALID_XXX, ResponseS, INVALID_SHARED){
do_something;
}
transition(INVALID_EXCLUSIVE, ALL_ACKS, EXCLUSIVE){
do_something;
}
transition(INVALID_SHARED, ALL_ACKS, EXCLUSIVE){
do_something;
}
Now, with the support of this patch, the above code can be re-written in fewer
lines as follows:
transition(INVALID_XXX, {ResponseX, ResponseS} , INVALID_WAITFORACKS){
set_nextState;
}
transition(INVALID_WAITFORACKS, ALL_ACKS, *){
do_something;
}
Note the reduction in the number of transitions. Now, this patch can save tones
of time and reduce number of lines of code substantially while writing a
complex protocol. Hope this helps!!!
- Sooraj
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2790/#review6219
-----------------------------------------------------------
On May 11, 2015, 10:23 p.m., Tony Gutierrez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2790/
> -----------------------------------------------------------
>
> (Updated May 11, 2015, 10:23 p.m.)
>
>
> Review request for Default.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> Changeset 10847:0c355889bd79
> ---------------------------
> slicc: support for transitions with a wildcard next state
>
> This patches adds support for transitions of the form:
>
> transition(START, EVENTS, *) { ACTIONS }
>
> This allows a machine to collapse states that differ only in the next state
> transition to collapse into one, and can help shorten/simplfy some protocols
> significantly.
>
> When * is encountered as an end state of a transition, the next state is
> determined by calling the machine-specific getNextState function. The next
> state is determined before any actions of the transition execute, and
> therefore the next state calculation cannot depend on any of the transition
> actions.
>
>
> Diffs
> -----
>
> src/mem/slicc/parser.py fbdaa08aaa426b9f4660c366f934ccb670d954ec
> src/mem/slicc/symbols/State.py fbdaa08aaa426b9f4660c366f934ccb670d954ec
> src/mem/slicc/symbols/StateMachine.py
> fbdaa08aaa426b9f4660c366f934ccb670d954ec
> src/mem/slicc/symbols/Transition.py
> fbdaa08aaa426b9f4660c366f934ccb670d954ec
>
> Diff: http://reviews.gem5.org/r/2790/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Tony Gutierrez
>
>
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
