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
