> 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. > > Sooraj Puthoor wrote: > Joel, please let me know if the above explanation makes sense. If no more > concerns, please give it a ship it! > > Joel Hestness wrote: > I understand what this patch does, but I'm not a fan of binding '*' to a > specific function. Changes to the SLICC language should be extensible, and > this is not. If this wildcard-next-state operator gets into mainline code, it > will be a fair amount of work to refactor it and make it extensible. > > Also, you (Brad) asked for more comments on the 'updated' patch, but the > patch wasn't actually updated on Reviewboard. Did something actually change? > > Sooraj Puthoor wrote: > Regarding the 'updated' patch, actually the patch did not change. > Apparently, a lot of patches from "Tony Gutierrez" got reposted without any > change to those patches. Probably, some scripting issue. > > Coming back to the comments on the patch, just to clear my confusion, are > you proposing '*' symbol should be replaced with some other symbol or are you > proposing that wildcard-next-state functionality should be implemented in > some other way? And how does this change makes SLICC nonextensible and > difficult to refactor? > > Joel Hestness wrote: > As I stated on the email thread: "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 [added: next state] > functions for different sets of "wildcard" transitions, and you'd avoid > introducing any implicit function declaration semantics." > > In other words, this is not extensible, because binding the meaning of > '*' to a specific function disallows other functions from being used to get > the next state. It seems like such a situation would arise pretty quickly as > soon as one starts grouping wildcard transitions. Further, this patch would > need to be effectively reverted to add multiple next state functions, and > we'd have to remove or deprecate uses of '*' as a wildcard operator. > > Nilay described what it would take to call next state functions in > transition headers in lieu of this patch (also on the email thread): > "There are several things need to be tackled here: > a. we specify states and events in transitions as 'ident' and not as > 'enum'. This is different from how we use them in rest of the code. > b. variables specified in the next state function call would need to be > added to the symbol table. This means that we would have to fix the set of > parameters anyway." > > As it stands, I oppose this patch. Nice-to-have features - like wildcard > next states on transitions, here - should not introduce new SLICC language > constructs unless the feature cannot be implemented any other way. > > Sooraj Puthoor wrote: > Thanks for the reply Joel. > I think this patch has to be looked upon as an extension of the exisiting > SLICC philosophy. > 1) Reserved functions: SLICC already has reserved functions like > "getState()" and "setState()" which are used to get and set states of "this" > transition. The getNextState function introduced by this patch is similar to > those functions except that its functionality is different. So, I think there > is no conflict with SLICC philosophy when we add one more reserved function > to SLICC. > 2) Third transition parameter as an expr: Well, one can add any logic (or > expression) in the getNextState() function in the same way one can add any > logic inside the existing getState function. There is absolutely nothing > which the getNextState function is doing different from the existing getState > fuction of SLICC in this regard, other than providing an interface function. > What is inside that interface function is completely under the control of > protocol developer. Now, regarding the tbe example which I showed, that was > just one example on how to use this new functionality. Additionally, one can > modify the set_NextState action (see my response to Jason) to have any > expression one needs so that the next state is computed with the help of any > complex expression of protocol developer's choice. > 3) '*' symbol is eternally bound to getNextState function: In the context > of this patch, '*' is the symbol used to distinguish normal trnasitions from > the wildcard_next_state transitions that require getNextState function. > Currently, we do not have any special meaning associated with '*' in SLICC; > so that is not conflicting with SLICC either. Now, if you have some other > symbol in mind which better reflects this wildcard feature, please let me > know. > 4) parameter list of getNextState: Currently, the getNextState() is > implemented to just return the next state from tbe entry or any other global > structure defined in the protocol file. This is a clever way of avoiding the > need to pass unknown number of parameters which might be needed in the > future. If someone wants to make a complex next state expresion, they can do > it in some action (like setNextState action in my example to Jason) and place > the result of this computation in the tbe. This is very much similar to > getState function which only looks into cache_entry or tbe_entry for finding > the next state. > > Now, this patch is not introducing just a new feature, but an incredibly > powerful feature for protocol writers saving them from the state explosion > problem of complex protocols and tones of time in the process. So, given the > merits of this patch, I think this patch should not be discarded. If some > developer finds the need of improvement for this patch in the future, they > can always improve on this patch as this patch is not breaking any of the > fundamental architetcure of SLICC.
I appreciate your effort on this. Apologies if the root of my opposition wasn't clear. Allow me to clarify: >> "I think this patch has to be looked upon as an extension of the exisiting >> SLICC philosophy." My opposition is that this patch is trying to extend a SLICC philosophy/vision without following a couple SLICC conventions. First, let's be clear that you're referring to the major SLICC philosophy/vision that is: to provide a compact domain-specific language with which to define state machines. I completely agree that collapsing transition declarations is very important for achieving compact code. I also agree that it would be great to introduce a way to collapse transitions which have the same input state and event, but different output states (i.e. the specific aim of this SLICC change). I oppose introducing the '*' symbol and binding implicit meaning to it to achieve this transition compaction. Using '*' does not follow two SLICC conventions: a) SLICC aims to avoid syntactic sugar. This patch adds a new and unnecessary symbol to the language. It is unnecessary, because the same desired functionality can be achieved simply by changing the way we parse transition headers. b) SLICC aims for transition handling be completely explicit in transition headers, which is important for compact code clarity. Current transition headers explicitly declare the current state, trigger event, and next state. Allowing variable output states will necessarily make it difficult to maintain this convention. However, using the wildcard operator as introduced by this patch really obfuscates the output state, requiring a user to know that '*' means they need to inspect getNextState() to see how the next state is set. At least if the output state were parsed as an expr, there would be an explicit call to the next state function, so a user would not need to know the implicit binding from '*' to getNextState(). These convention problems are in addition to the binding only allowing a single getNextState function and the longer-term problems that stripping out the '*' operator later will be painful. Given that this is an advanced feature, I don't feel that the merits of this patch outweigh the slacked SLICC conventions that it imposes. I feel strongly that this should be implemented without adding the '*' symbol to the language. Just a quick note: >>"I think there is no conflict..." >>"that is not conflicting with..." Arguments such as these can't really be used to support a patch. Patches should also avoid breaking compilation, for instance, but this is a vacuous requirement. Patches should do something to improve the codebase rather than not do something that harms it. Statements like this _can_ be used to refute arguments that claim conflicts, but I've neither claimed that getNextState() conflicts with SLICC reserved functions nor that introducing the '*' symbol conflicts with other SLICC syntax. - Joel ----------------------------------------------------------- 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
