On Tue, 19 May 2015, Brad Beckmann wrote:
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.
stallPort() gets converted to scheduleEvent(Cycles(1)); How is this
stalling the port? What ever statement follows stallPort() would still be
executed. Please provide some code snippet so that I can understand how a
port will get stalled.
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.
Note that SLICC is a language. SLICC supports functions and we can define
a function check_next_cycle() that calls scheduleEvent(Cycles(1)), say in
RubySlicc_utils.sm. We would need to provide a prototype for
scheduledEvent() function which is fine with me. Similarly you can define
another function stallPort() which also does the same thing. I am not in
favor of changing the language just for these two functions. The
readability of code in *.sm files would not change at all.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
