On 07/09/11 03:42, Nilay wrote: > On Fri, July 8, 2011 11:40 pm, nathan binkert wrote: >>> I prefer to retain it. There are places where we check if RUBY is set or >>> not, and checking for whether PROTOCOL is set or not, would not make >>> sense, >>> though it would yield the same information. >> What's the point of it? It's just redundant. The existence of both >> variables is simply an accident of history during the merge process. >> >> Basically, we should just check that PROTOCOL is in env or that >> PROTOCOL is not None and that would signify that we've got ruby >> compiled in. Having two variables doesn't gain us anything. We could >> rename PROTOCOL to RUBY_PROTOCOL. I don't care enough to fight, I >> just think that reducing the number of compile time variables is >> always a good thing. >> >> All this said, I think that actually the correct thing to do for se.py >> is to essentially do an "if 'PROTOCOL' in env" then add a --ruby >> option to the command line. Then do an "if '--ruby' in sys.argv" check >> to determine if the ruby options should be added. I know this is >> convoluted, but the classic memory system does exist even when ruby is >> compiled in, and without doing this in two steps you can't use the >> classic memory system if you have ruby compiled. That IMHO makes no >> sense. > It might appear as if coherence protocols are the only thing that is there > to ruby. If some time down the line, protocols were to become optional > meaning you could use some part of ruby with out using the coherence > protocols themselves, would you still want to go on with the check on the > variable PROTOCOL? The variable PROTOCOL should only be used for things > related to protocols themselves. Why would you want to use it to enable / > disable options for, say, topology? > > -- > Nilay > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
Are we talking about just in the scons stuff, or in C++ as well? Hopefully the scons stuff isn't so complicated that it's a big deal to separate out the "am I building ruby" vs. the "what protocol am I using" cases. If it isn't a big deal and there aren't a bunch of places either is checked (maybe a half dozen or so?) then I think keeping them separate for a "what if" is premature optimization and does complicate the build somewhat. Maybe it's just time to always build ruby? Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
