> 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.
>
> Sooraj Puthoor wrote:
> 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!!!
Ah, thanks for the thorough explanation. Do you think you could add this to the
wiki?
- Jason
-----------------------------------------------------------
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
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
