On Wed, 20 May 2015, Brad Beckmann 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.
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.
I think you got me wrong. AMD has suggested the following syntax
transition(Current State, Event, *)
{
actions;
}
I am suggesting:
transition(Current State, Event, getNextState(address))
{
actions;
}
Anyways, I looked at the code and I think what I am suggesting is doable
but would require time. 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.
You can go ahead with the patch for the time being. If I write a patch
before you commit, then we will drop this patch. Or else I'll change it
later.
--
Nilay
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
