> On May 29, 2015, 12:34 a.m., Brad Beckmann wrote: > > Any more comments on the updated patch? > > Joel Hestness wrote: > Um... nothing changed in the updated patch? > > I still dislike binding implicit meaning to '*'. > > Sooraj Puthoor wrote: > With the "wildcard next state" approach, the programmer do not know the > next state while writing the protocol. So, the programmer has to write a > transition with the only information he has at that time which is the next > state can be "any state". From a programming perspective, I think '*' is the > most appropriate character to capture/represent this sentiment. Even more so > becasue '*' is widely used in programming languages as the wildcard character. > > Now, the question "which is the next state?" is resolved by the > getNextState() function during runtime. Please see my detailed response to > Jason's comment to understand how exactly this functionality can be used.
Joel, please let me know if the above explanation makes sense. If no more concerns, please give it a ship it! - Sooraj ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2790/#review6420 ----------------------------------------------------------- On May 26, 2015, 7:45 p.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2790/ > ----------------------------------------------------------- > > (Updated May 26, 2015, 7:45 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10820:5064fb0968bb > --------------------------- > 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 df2aa91dba5b0f0baa351039f0802baad9ed8f1d > src/mem/slicc/symbols/State.py df2aa91dba5b0f0baa351039f0802baad9ed8f1d > src/mem/slicc/symbols/StateMachine.py > df2aa91dba5b0f0baa351039f0802baad9ed8f1d > src/mem/slicc/symbols/Transition.py > df2aa91dba5b0f0baa351039f0802baad9ed8f1d > > 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
