Now that the other GEM5 issues are mostly resolved (thanks everyone!), I wanted to discuss the protocol directory issue in more detail. I'm completely fine with recompiling all files when changing protocols. I would just like the ability to have two different M5 binaries, using different protocols, co-exist in the same M5 tree. A solution similar to the current ALPHA_SE and ALPHA_FS binaries would be great.
I want to better understand the motivation to compile multiple protocols into the same M5 binary. In my opinion, the comes down to the tradeoff of compile complexity and time vs. binary flexibility and testing. From my perspective, there is a lot of work involved to change the Ruby/SLICC interface to support a protocol template parameter. Though I'm sure with enough effort, it could be done. I assume that each protocol could be selectively compiled into the m5 binary and there would be some way to identify what specific protocols a M5 binary supports. Is that correct? So I'm curious to understand why we want to treat protocols differently from the compile time options like the ISA and SE vs. FS? All of these features seem to involve a lot of specific code used only by that feature. To me that seems to best match making them all compile time features, but I probably don't understand all the issues involved. Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: Friday, July 31, 2009 6:18 PM To: M5 Developer List Subject: Re: [m5-dev] Fwd: GEM5 Issues > 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. The difficulty with the former is not the filenames, but symbols. It would be easy enough to do src/mem/protocol/MI_example and src/mem/protocol/MESI_CMP_directory and pick which set of autogenerated files to link into the binary based on the PROTOCOL variable. The question that I don't know is if SCons will force a recompile of those files anyway when you switch PROTOCOL. We could try. This would not give you two different m5.opt binaries when you compile, but would potentially save time when you switched between them by not recompiling stuff. > 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? I don't think so. Scons tends to be smart about things and it gets in your way when you try to play tricks. Right now, we do have a similar problem when we build say both ALPHA_SE and ALPHA_FS, but what actually happens under the covers is that every file that is shared between the two (without any differing #defines) is still compiled twice. I'm nearly done with a big change to SCons that fixes this problem. I can work the protocol into this framework as well. The real solution in the long run is to allow multiple protocols to be compiled into a single M5 binary. This isn't hugely difficult, but would require some work because as things stand now, there will be symbol conflicts. The solution is to make generated code and code that uses generated code take the PROTOCOL as a template parameter. I'll have to look through ruby/slicc to see how much work this will be. _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
