Reponses below marked with [BB]:
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay Vaish
Sent: Tuesday, May 19, 2015 3:41 PM
To: Default
Subject: Re: [gem5-dev] Review Request 2808: slicc: improved stalling support
in protocols
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.
[BB] Sure, if someone were to insert code after the call to stallPort(), then
that would be executed, but the port is still stalled on the current message.
We use this message so that our in_port logic is easier to read and doesn't
lead to deadlock.
In_port(...) {
if (buffer.isRead()) {
peek (...) {
If (<conditions exist to process the next message>) {
...
} else {
stallPort();
}
}
}
}
>
> 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.
[BB] Just because you don't believe this improves readability, doesn't make
that true for others. You are welcome to post the patch you are proposing and
I will give it a ship it. I prefer to do it in a different way because I think
it improves readability.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
