I failed to mention earlier that the parameter is used in the protocol files so it isn't just simple C++. However, it is simple enough to make SLICC generate the correct C++ since RubySystem has static functions that provide the block size bits. Once these functions are no longer static, the SLICC solution is a little more complicated, but I got something in mind that should work. Consider the problem resolved.
Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of nathan binkert > Sent: Friday, January 15, 2010 11:53 AM > To: M5 Developer List > Subject: Re: [m5-dev] [PATCH 00 of 41] Ruby Config Updated Patches > > > Unless there's ever a reason why a user would want to set this low > bit > > to something other than the log2 of the block size, then this value > > should just be calculated in C++, in my opinion. > I would agree with this. > > > The reason it doesn't work is because math operations on proxy values > > have to be explicitly supported in the proxy code, and log isn't one > > that we support. (Actually I'm not sure it's possible to support > > function calls on proxies, just operators.) In theory we could add > > support for exp or log on proxies (if we defined an operator) but it > > would be easier to move it to C++ unless there's a real need here. > > Yep. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev