Hi guys, On Tue, May 19, 2015 at 6:04 PM, Nilay Vaish <[email protected]> wrote:
> On Tue, 19 May 2015, Sooraj Puthoor wrote: > > >> >> 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.... >> >> > 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. > If I follow Nilay's suggestion, I think I agree. Using '*' to designate the specific function 'getNextState()' binds implicit semantics of a getNextState function when it is present. In Sooraj's example, you'd only be able to get the next state from the TBE's nextState variable (unless you have a way to pass parameters to getNextState() somehow?). If the third transition parameter were parsed as an expr, you could put in different functions for different sets of "wildcard" transitions, and you'd avoid introducing any implicit function declaration semantics. Joel -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
