In SLICC we also use commas to separate parameters passed into a function or class...like most other languages I'm aware of. Using semi-colons seems awkward.
I understand your point about message buffers, but that is only a problem because we are trying to pass these objects as parameters. Actually the fact that we declare and essentially pass the message buffers out of machine rather than pass them in is very awkward altogether. Many years ago we actually had a separate file the declared all the virtual channels needed in the protocol. Perhaps we should go back to that...maybe even using python to declare virtual channels. That would be a far less confusing notation than what is currently supported. I'm not sure where all this confusing SLICC notation is going and I would prefer if we just kept it as is. I think we all rather be doing interesting research rather than conforming our protocol files to some new notation for the sake of change. Brad -----Original Message----- From: Nilay Vaish [mailto:[email protected]] Sent: Tuesday, December 02, 2014 12:48 PM To: Beckmann, Brad Cc: gem5 Developer List Subject: RE: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable memb... On Tue, 2 Dec 2014, Beckmann, Brad wrote: > Hi Nilay, > > Could you explain the motivation behind this change? What was wrong > with the previous notation that data member declarations are separated > by commas rather than semi-colons? I think in most places in SLICC we use comma to separate the attributes of a variable. So, having a different meaning for comma when used while declaring parameters does not seem right to me. Second, message buffers typically have several attributes with them. If we were to retain the comma as separator, then it would not be possible to specify message buffers as parameters. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
