Thanks for getting these patches out, Brad. On Thu, Jan 14, 2010 at 10:19 PM, Brad Beckmann <brad.beckm...@amd.com> wrote: > - These patches do not remove the old ruby config and rubymem files. > However, once these patches are checked in, those old files won't be needed. > Anyone have an opinion on how long they would like those files to stick > around? I would like to delete them as soon as we can.
I think these files should be deleted as soon as they are no longer needed... i.e., go back in the patch queue to the patch where we stop needing them to compile and run and do the 'hg rm' as part of that patch. I didn't do that sooner since it's a little more convenient to just look at the file than to go back in the hg history, but now that we have all these patches finished, there's no need to keep them around, and no point in having patches to delete them that are separate from the changeset where we logically stopped needing them. > - There are a few places where the block offset (i.e. the l2_select_low_bit) > is defaulted to 6 assuming 64-byte cache blocks. I would like to instead > take the log2 of RubySystem's block_size_bytes parameter, however the > following code will not work: > l2_select_low_bit = Param.Int(math.log((Param.RubySystem(Parent.any, "block > offset")).block_size_bytes, 2), "") > I would be interested to hear any suggestions people have to make something > like this work. 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. 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. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
