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

Reply via email to