On Sat, 9 Jul 2011, nathan binkert wrote:
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?
In the long run, we want to get rid of as many compile time options as
possible. If there are useful parts of ruby that are not part of a
protocol, then we should always just compile them in.
Though I was thinking about se.py all the time, from Gabe's and Nate's
response, it seems that my comment was interpreted for setting compilation
options. I would say even for compilation, I prefer using RUBY rather than
PROTOCOL. It might be so because that's what I have been doing all the
time. I almost never use PROTOCOL.
I am fine with elimination of RUBY as a compile time option. But I still
prefer retaining RUBY as a variable and using it to check whether or not
to build certain components, like we do right now. This variable would be
set depending on whether PROTOCOL is supplied at compile time or not. As
Nate suggested in a previous email, --ruby is provided as an option only
if PROTOCOL was present in the build env.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
