> 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.
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. - Nilay ----------------------------------------------------------- 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
