> On May 14, 2015, 2:53 p.m., Nilay Vaish wrote: > > First, why do you need both stallPort() and check_next_cycle()? Both are > > going to call scheduleEvent(Cycles(1)). > > > > Second, why not just expose scheduleEvent() function and let the protocol > > author use it in whatever way they like. > > Why add a new keyword for calling a function that simply calls another > > function? > > Brad Beckmann wrote: > stallPort() is only meant to be used within an in_port, while > check_next_cycle() is a pre-defined function that can be called within an > action. You are correct that this patch could just use check_next_cycle() > and avoid introducing stallPort(). I preferred the stallPort() call within > the in_port just to make it clear that the entire port is being stalled when > stallPort() is called rather than triggering an event. > > Nilay Vaish wrote: > stallPort() not actually stalling the port. It is just calling > scheduleEvent(). > Is this not misleading? Stalling should mean nothing would get processed > after the call to stallPort(). > > Secondly, why do we want to add these special cases? Let's just expose > scheduleEvent() > function through some .sm file and the protocol author can directly use > it for whatever > purpose they want to. Or else, you can add stallPort() and > check_next_cycle() as functions in some .sm > file and use them in your protocols. I think we are unnecessarily adding > special > cases to the SLICC compiler.
StallPort is in fact stalling the port by not dequeuing the message from the message buffer. Nothing eles on that port will be processed if one does dequeue the head pointer. SLICC has not supported direct event queue manipulation. These APIs allow the experience SLICC programmer to manage message processing without calling the event queue APIs. You are absolutely right that these two functions generate the same code and could be replaced by adding the event queue APIs to the RubySlicc*.sm files. It is simply a choice between the readability of SLICC protocols versus minimizing the SLICC API. - Brad ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2808/#review6261 ----------------------------------------------------------- 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/2808/ > ----------------------------------------------------------- > > (Updated May 11, 2015, 10:23 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10865:959f954b7dca > --------------------------- > slicc: improved stalling support in protocols > > Adds features to allow protocols to reschedule controllers when conditionally > stalling within inport logic or actions. Also insures that resource and > protocol stalls are re-evaluated the next cycle. > > > Diffs > ----- > > src/mem/slicc/parser.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/slicc/ast/InPortDeclAST.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/slicc/ast/IsValidPtrExprAST.py > fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/slicc/ast/__init__.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/slicc/ast/FuncCallExprAST.py > fbdaa08aaa426b9f4660c366f934ccb670d954ec > > Diff: http://reviews.gem5.org/r/2808/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
