Thanks Derek and Nate for the replies. Overall, it sounds like no one is directly working on the four issues I outlined below, so I'll put them on my to do list. The NetDest and DMA controller issues are most pressing, so I'll work on those first. Later on I'll work on the SLICC errors and protocol folder issues. Below is a more thorough response to your questions.
- Supporting multiple protocol folders. To answer Nate's question, it is the later reason. Because SLICC generates different classes with the same name depending on the protocol, I don't think it is possible to former. Could we generate all protocol files outside of the build directory and then tell scons to copy only the necessary protocols files to the appropriate build directory? For example, have SLICC generate the MI_example and MESI_CMP_directory protocols in the respective directories: src/mem/protocol/MI_example and src/mem/protocol/MESI_CMP_directory. Then have scons copy the MI_example directory to the build directory: build/ALPHA_SE_MI_example/mem/protocol and copy the MESI_CMP_directory to build/ALPHA_SE_MESI_CMP_directory/mem/protocol without copying the other protocol's generated files. Therefore, scons can maintain that the m5 executables under the directories build/ALPHA_SE_MI_example/ and build/ALPHA_SE_MESI_CMP_directory/ depend on only the files listed in those directories. Does that make sense? Will that work with scons? - SLICC generation parsing error support in scons Of the four issues I listed, this is definitely the lowest priority, so I'm happy to put it on the back burner. I just wanted to point out right now the ParseError just provides a file name and the LexToken that describes the error. If you know that the third parameter of the LexToken is the line number, then that is all the information an experience SLICC programmer needs to debug. However, I'm concerned for novice SLICC programmers who may need more information. - 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. - DMA assumptions in Ruby. If you look at line 84 in my version of ruby/slicc_interface/RubySlicc_ComponentMapping.hh, you'll see a direct reference to DMA. I am confused whether we're still sticking to the strategy to use "#define"'s for machine types to handle these errors, or do you have plans to deprecate the "#define"'s? I thought part of the motivation to remove the NetDest functions in RubySlicc_ComponentMapping.hh was because they used the "#define"'s? Even if you add a DMA #define, The ruby/system/DMASequencer.cc relies on the DMARequestMsg type and other various DMA classes. Could the DMASequencer use the CacheMsg class instead...we could rename CacheMsg to SequencerMsg? Or we could just move DMARequest and the other DMA support to RubySlicc_Exports.sm? Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Derek Hower Sent: Thursday, July 30, 2009 10:34 PM To: M5 Developer List Subject: [m5-dev] Fwd: GEM5 Issues ---------- Forwarded message ---------- From: Derek Hower <[email protected]> To: M5 Developer List <[email protected]> Date: Thu, 30 Jul 2009 23:24:08 -0500 Subject: Re: [m5-dev] GEM5 Issues On Thu, Jul 30, 2009 at 7:46 PM, Beckmann, Brad<[email protected]> wrote: > Hi All, > > Tushar and I have noticed a few issues with GEM5 and we were wondering > if anyone had plans to fix them. If not, we'll go ahead and check in > fixes to the global repository. I just want to make sure we're not > stepping on anyone's toes. Glad to get some help!! > > - Fix SLICC so that protocol generated files are created in separate > protocol specific folders. Currently they are created in the same > mem/protocol folder overwriting older files (eg. > build/ALPHA_SE/mem/protocol//ControllerFactory.cc). Go ahead with this one. > - Fully integrate SLICC parsing errors into scons. Right now the error > messages don't give any useful info. Should we hold off on fixing this > until SLICCer is added to GEM5? I wouldn't hold off. SLICCer is still indefinitely postponed, at least on my end. I don't expect to work on it until November-ish. Even after SLICCer is around, I think it would be wise to maintain SLICC support for a while so this would be a good fix. > - Support broadcast protocols with NetDest ruby functions. I notices > that one of Derek's recent checkins removed all the NetDest functions in > RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol > specific, and needed to go. However there were a few general ones that > are needed by any broadcast based protocol. Are there plans to add > these back into the tree? Those weren't just removed because they are old. A lot of them were removed because they call a function similar to "mapL2toDirectoryNode," which assumes that there *is* an L2 in the system. We can put these functions back in (and I was planning on doing it as protocols are revisited), but we need to do it in a more generic way. For example, one of the things we are doing to get MESI_CMP_directory working again is removing map_L1CacheMachId_to_L2cache and replacing it with mapToAddressRange(low_bit, high_bit). Low bit and high bit are set at configuration time, and correspond to the address bits that select the L2 bank. If you could be more specific about which functions you're concerned about, we could brainstorm and come up with a new way to do the mapping. > - I appreciate that a lot of the controller assumptions on the ruby side > have been removed. However, it appears that Ruby now assumes a DMA > controller is present. Is there plans to clean this up. I don't think Ruby actually assumes that one is present (if it does it shouldn't). The existing configuration files certainly do, though, mostly because Rocks can't run without one. If you create a configuration that doesn't instantiate a DMA controller, I think you'll be OK. The reason Rocks needs a DMA controller is mostly due to the fact that Ruby handles data now and can't just ignore DMA accesses like it used to. I don't know enough about what M5 does with DMA to know if that is a problem or not. > > Again, we're happy to fix this stuff up ourselves. I just want to be > sure there aren't plans already in progress. > > Thanks, > > Brad > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
