> - In hindsight, one may see the items in this patch as unrelated, but I > initially created this patch with the sole goal of adding large memory > support to Ruby. It turned out I encountered a lot of issues throughout the > code, and there are more to come. That being said, I have no problem using > the "-X" option to separate these out to multiple changesets when I commit > them.
I understand completely that this is in hindsight. It would just make things clearer for everyone if you broke things up more. The term unrelated was probably not quite right. Some things were unrelated, but it's more than that. When you can make things independent, that's good. > - Sure, I can modify SparseMemory to be more abstract and move it to m5/base, > but I probably then need to change SparseMemory to use the base/hashmap.hh > object directly and not use gems_common/Map.hh. Directly using STL was one > of things that original authors of Ruby never liked and that is why you don't > see much direct usage of STL in Ruby today. I agree we need to start more > tightly integrating Ruby and M5, and this is a good example to do so. It may > take a while before I can find time to do this, but I'll try to give this a > shot as soon as I can. I used to avoid using the STL when I was developing ASIM because it wasn't super stable, complete, or always available, but given it's current state, there's no good reason to do that now. It is my firm belief that everything in gems_common should be deprecated and removed with the exception of the stuff in util which is largely duplicates of stuff in base/intmath, but not completely. We'll also have to figure out the overlap between src/base refcounting stuff and the src/mem/gems_common stuff Does anyone have any strong objection to this attitude? > 5. If the cache size can only be specified at the KB granularity, then how do > perform small size tests like the random tester? Actually, upon further > investigation, while the ruby-language configuration code says the size is in > KBs, I don't see any 1024 multiplication in the actual CacheMemory::init > function. How about we clear up the confusion and declare the cache size in > bytes? What we really need to do is switch to using the python configuration stuff :) Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
