Re: [Gems-users] non-cacheable memory


Date: Tue, 30 Jan 2007 17:55:21 -0600
From: Dan Gibson <degibson@xxxxxxxx>
Subject: Re: [Gems-users] non-cacheable memory
IF you return 0 directly from ruby_operate, no other part of ruby will see, profile, cause delays for, etc., the accesses. Be careful to only return 0 on the correct subset of accesses, and be advised that if the accesses are not rare events then returning 0 will distort your performance numbers.

Dave Z. wrote:
--- Mike Marty <mikem@xxxxxxxxxxx> wrote:

  
If you are not interested in modeling the memory
      
system affects of issuing
    
a request to memory, possibly incurring
      
interconnect delays and etc., then
    
sure, return a fixed number of stall cycles to
      
Simics
    
This actually won't work.  You first need to stall
Simics, then after the
stall elapses, Simics will ask again if it can
proceed and you need to
then return a stall of 0.
    

If I return a value of 0 for memory requests involving
certain memory locations, will this work then? Ruby
won't see those locations in the cache and no misses,
hits, transitions, etc. will be profiled. But the
instruction fetches or other memory operations related
with those certain memory locations will still be
profiled, right? Please correct me if I'm wrong.

Thanks,

Dave


 
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile.  Get started!
http://mobile.yahoo.com/services?promote=mail
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.


  
[← Prev in Thread] Current Thread [Next in Thread→]