> 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. > > Sooraj Puthoor wrote: > 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....
On 5/19 Nilay wrote via email "I understand the thinking behind using '*'. I don't understand why do we want to fix the associated function's name and its set of parameters. I think we should be more general over here. I would against suggest that we allow 'expr' instead of 'ident' as next_state token. In TransitionDeclAST.py, we should check that the type of the next_state is State, which we always assume exists." (I believe you meant to say "again" not "against", correct?) Current the state functions (getState, setState, etc.) are hard coded to particular function names. What you are suggesting seems like it could be helpful to a very experienced SLICC developer, but changing the harde coded names go beyond this patch. - Brad ----------------------------------------------------------- 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
