Thanks everyone for the comments.  I won't be able to check in my patch(es) 
today, but will work on it more next week and try to commit them in a week or 
two.

First to answer Nate:
- 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.
- 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.

Now to answer Derek:
1. Yeah, the "True" and "False" tests were a mistake.  I failed to notice the 
lowercase loop.
2. Yes, it is very easy to use the sparse memory object in other protocols.  It 
is just a simple change in the setState function.  Does the latest version of 
the memtest-ruby regression tests cover those other protocols?  If so, is there 
anything special required to run them?
3. No problem, done.
4. At one point in time, internally we were encountering a syntax error for 
that line.  However I can't seem to recreate it right now.  Regardless, I 
shouldn't check that in.  I'll make sure it is not included in my check-in.
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?

Brad

-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of 
Derek Hower
Sent: Saturday, September 12, 2009 6:20 AM
To: M5 Developer List
Subject: Re: [m5-dev] Large Memory support in Ruby

Great patch Brad.  A few comments/questions:

1)  Why is this necessary immediately after converting the string to lowercase?

   for (size_t i=0;i<str.length();i++)
     lower[i] = tolower(str[i]);
-  if (lower == "true")
+  if (lower == "true" || lower == "True")
     return true;
-  else if (lower == "false")
+  else if (lower == "false" || lower == "False")
     return false;

2) Would it be possible to update MOESI_CMP_directory and
MESI_CMP_directory to utilize these changes as well?

3) In MI_example-homogenous, could you change the option from -u to
-U?  -u is already used in rocks, which creates a problem because
rocks and ruby share the same command line.

4) Why did you comment this out? (in cfg.rb)

+    #assert (val.is_a?(Integer) or val == "rand"),
"RubySystem.random_seed takes either an integer value or the string
\"rand\""

5) In cache memory, why do you account for the case where cache_size is zero?

-Derek

On Fri, Sep 11, 2009 at 6:09 PM, Beckmann, Brad <brad.beckm...@amd.com> wrote:
> Hi All,
>
>
>
> Attached is a patch I would like to check in that allows Ruby to support a
> very large memory address space and high core count.  Currently ruby uses a
> flat array to store the memory state of the system.  This works well when
> the simulated system is roughly 4 GB or less, but is not practical for 128
> GB+ systems.  The patch provides the Directory Memory a sparse memory data
> structure, which is essentially a hierarchical map.  The patch also includes
> various bug fixes including configuration string parsing and debug fixes.
>
>
>
> Let me know what you think.  If I don't hear any complaints within a week,
> I'll go ahead and check it in.
>
>
>
> Brad
>
>
>
> _______________________________________________
> 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


_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to