> On May 12, 2015, 8:47 p.m., Nilay Vaish wrote: > > There are two problems I have with this patch. Firstly, it changes the > > generally > > accepted meaning of '*'. Secondly, it is adding another keyword to the > > language > > which is, in my opinion, not required. Instead, the transition construct > > should > > be upgraded so that it recognizes that the final state argument can be > > anything whose type > > is state. This would allow us to name the function whatever we want it to > > be. > > Brad Beckmann wrote: > What do you mean it changes the meaning of '*'? That symbol is not > currently used in SLICC. SLICC has been designed not to directly expose > pointers to the programmer, so the '*' symbol is currently unused. > > Upgrading the transistion construct requires a pretty significant change > to the parser. The current patch is much cleaner and the notation is > simplier.
Hi Nilay, The thought behind the use of '*' was that the nextState could be anystate returned by the getNextState() function....It simply means we do not know the state in advance... Please let us know if you have any other symbol in mind which can better represent this behaviour.... - Sooraj ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2790/#review6195 ----------------------------------------------------------- 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
