> 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.
This can be done right now by using a different build directory for each protocol. You're used to having a scons target of "build/ALPHA_FS/...", you can however do something like build/<protocol>/build/ALPHA_FS and that will cause things to be built in a different directory. You can even specify a full path that is not a subdirectory of the m5 dir. I should note that there is a limitation in the current SCons system in that the directory that ALPHA_FS, etc lives in must be called build. (The new version our stuff will have this limitation removed.) > 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. I actually want to get rid of ISA and SE/FS as compile time parameters. It's a long term goal, but I'd prefer not to do things that make it worse. Basically, the problem is that m5 currently rebuilds everything if any compile time parameter changes. Because of this, as we add more compile time parameters, less of the simulator will be properly tested. (I'm pretty sure that few people compile all combinations of ISA and emulation.) As protocols multiply, this will get worse. Another downside of having multiple binaries is that it's easier to accidentally have one that is out of date. This can be particularly troublesome when running hundreds of simulations. I'm nearly done with a big overhaul of our SCons code that at least will not recompile files that don't depend on ISA or emulation or protocol. (the #defines will have to be explicitly #included and options to the Source directive in scons determine which #defines are available). This will significantly improve compile time and will probably solve most of the problem. We could stop here, but once this is done, it might not be hugely difficult to compile in multiple protocols if we just wrap the code in a protocol dependent namespace. Similarly, this might be a short cut for getting rid of ISA and FS/SE. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
