I was hoping that there was a better way to solve this...I'm glad you found it! However I'm confused why you don't think "MachineType::L1Cache" is legal SLICC code? SLICC can reference a particular machine type by simply removing a colon, "MachineType:L1Cache". This will translate to "MachineType_L1Cache" in the generated code. Simple broadcasts in systems with little hierarchy can use this broadcast function without too much complexity. However, systems with more hierarchy will require a more comprehensive solution. For example, if you want to broadcast only to those L2 caches that are within you same chip. I know you recently changed the configuration infrastructure to support heterogeneity and I'm not quite clear how the new configuration infrastructure specifies hierarchy in the ruby-language files. Could you elaborate or point me to an example? It would be great if we could get the new configuration infrastructure to generate functions such as: "NetDest getLocalL2Caches(MachineID machID)". That is what I was trying to get at with adding a hack to slicc/symbols/Type.cc.
Thanks, Brad -----Original Message----- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Derek Hower Sent: Monday, August 03, 2009 11:17 AM To: M5 Developer List Subject: Re: [m5-dev] Fwd: GEM5 Issues > > - NetDest support in RubySlicc_ComponentMapping.hh > > The functionality I'm particularly concerned about is setting the destination > of a message so that it broadcasts to all L1 caches or all directories. > Before, all of those helper functions were in RubySlicc_ComponentMapping.hh. > If we don't want those helper functions on the ruby slide any more, we could > add them to the generated MachineType.cc file by hacking the "if > (m_isMachineType)" statement in slicc/symbols/Type.cc. It wouldn't be the > first hack added to that file or the ugliest hack in SLICC. :) If you have > a suggestion for a more elegant solution, I'm happy to hear it. I think the right wat to do this would be to a broadcast(MachineType) method in RubySlicc_ComponenMapping.hh that looks like: NetDest broadcast(MachineType type) { NetDest dest for (int i=0; i<MachineType_base_count(type); i++) { dest.add(MachineID(type, i)); } return dest; } Then in SLICC have a line that looks like: out_msg.Destination := broadcast(MachineType::L1Cache); The problem is that MachineType::L1Cache is not legal SLICC code. Adding this would require a change to parser as well as the code generator. It would be a bit of work, and the question is, is it worth it to make this fix given that SLICCer will (eventually) happen? I'm not sure. Perhaps a comprimise between right and fast would be to pass something to broadcast that SLICC does know about. For example, you could pass a string to broadcast and then use string_to_MachineType to get the MachineType. Obviously, this is slow and you probably don't want to do it, but something similar could work. (use MachineType_from_base_level?). Other ideas? _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
