> On May 12, 2015, 10:02 p.m., Jason Power wrote:
> > src/mem/slicc/ast/PeekStatementAST.py, line 69
> > <http://reviews.gem5.org/r/2789/diff/1/?file=45006#file45006line69>
> >
> >     Could you explain why an exception is required here? Looking through 
> > the rest of the gem5 code, the only other times we use exceptions are in 
> > the python-c++ bindings and our string wrappers.
> >     
> >     If using the exception is really required (or if it is significantly 
> > easier to implement with exceptions) I don't have any problems with it, but 
> > it seems like there is almost always a more elegant solution. I think it's 
> > worth a little explanation since we so rarely use them in gem5.
> 
> Brad Beckmann wrote:
>     I think exceptions are needed because SLICC creates the AST in a single 
> pass.  I certainly don't know how to do this in another way.  Derek Hower 
> could provide you a more detailed response.

I am also against using exceptions for doing actual work.  Exceptions are for 
error handling, not for writing code.
I think the following would work.  The SLICC syntax would be:

in_port(ResponseQueue_in, {ResponseMsg, TgtResponseMsg}, responseFromDir, 
rank=3)

The order of the message types would decide the order in which each type is 
tried.

The generated code would look like:
// Declare message
const $mtid* in_msg_ptr M5_VAR_USED;
if (check for first type) {
   do the required work
}  else if (check for next type) {
} else {
  fatal / panic.
}


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2789/#review6216
-----------------------------------------------------------


On May 11, 2015, 10:22 p.m., Tony Gutierrez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2789/
> -----------------------------------------------------------
> 
> (Updated May 11, 2015, 10:22 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10846:0f9c2e771fd7
> ---------------------------
> slicc: support for multiple message types on the same buffer
> 
> This patch allows SLICC protocols to use more than one message type with a
> message buffer. For example, you can declare two in ports as such:
> 
>   in_port(ResponseQueue_in, ResponseMsg, responseFromDir, rank=3) {
>   in_port(tgtResponseQueue_in, TgtResponseMsg, responseFromDir, rank=2) {
> 
> 
> Diffs
> -----
> 
>   src/mem/protocol/RubySlicc_Exports.sm 
> fbdaa08aaa426b9f4660c366f934ccb670d954ec 
>   src/mem/ruby/slicc_interface/AbstractController.hh 
> fbdaa08aaa426b9f4660c366f934ccb670d954ec 
>   src/mem/slicc/ast/InPortDeclAST.py fbdaa08aaa426b9f4660c366f934ccb670d954ec 
>   src/mem/slicc/ast/PeekStatementAST.py 
> fbdaa08aaa426b9f4660c366f934ccb670d954ec 
>   src/mem/slicc/symbols/StateMachine.py 
> fbdaa08aaa426b9f4660c366f934ccb670d954ec 
>   src/mem/slicc/symbols/Var.py fbdaa08aaa426b9f4660c366f934ccb670d954ec 
> 
> Diff: http://reviews.gem5.org/r/2789/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to