Re: [Gems-users] ruby results


Date: Mon, 27 Nov 2006 17:17:38 -0600
From: Dan Gibson <degibson@xxxxxxxx>
Subject: Re: [Gems-users] ruby results
Add a printf("foo\n") to ruby's simics/commands.C in the operate memory function and the observe memory function and recompile. If Ruby is receiving requests, there should be a lot of foo's printed.

Dave Z. wrote:
simics> phys_mem.info
Information about phys_mem [class memory-space]
===============================================

                  Snoop device : none
                  Timing model : ruby0



Dave.

--- Dan Gibson <degibson@xxxxxxxx> wrote:

  
Try the following after ruby0.init:
phys_mem0.info
phys_mem.info

What does Simics print?

Dave Z. wrote:
    
Yes, the SIMICS_VERSION is set to 3.0 and the
GEMS_ROOT is "..", which is fine. After loading
      
Ruby,
    
Simics runs very fast as if Ruby is not working
      
(which
    
is true because the results are zero).

Thanks,

Dave

--- Dan Gibson <degibson@xxxxxxxx> wrote:

  
      
Did you change the SIMICS_VERSION settings in
Makefile.simics_version 
and did you change the GEMS_ROOT setting in the
        
two
    
module makefiles? 
After changing, you must perform a full
        
recompile.
    
Dave Z. wrote:
    
        
I'm using the -stall option when I'm starting
      
          
Simics.
    
        
But the results are all zero. In my benchmarks,
      
          
I'm
    
        
using processor_bind to bind a thread to a
      
          
processor.
    
        
For example, the layout of my benchmarks are as
follows:

Thread0 (assigned to cpu0)
MAGIC_BREAKPOINT;
...

Thread1 (assigned to cpu1)
...
MAGIC_BREAKPOINT;

So, when Thread0 reaches the breakpoint, I load
      
          
ruby
    
        
and when Thread1 reaches the breakpoint, I dump
      
          
the
    
        
ruby stats. But the results I get are all zero.
      
          
The
    
        
Simics ouput is as follows:

simics> c
[cpu0] v:0x0000000000011184 p:0x001fdefd184 
          
magic
    
(sethi 0x40000, %g0)
Setting new inspection cpu: cpu0
simics> load-module ruby
successful installation of the ruby timing
          
model.
    
simics> ruby0.init
Ruby Timing Mode
Warning: optimizations not enabled.
Creating event queue...
Creating event queue done
Creating system...
  Processors: 2
Creating system done
Ruby initialization complete
simics> c
[cpu1] v:0x00000000000130c0 p:0x001d68130c0 
          
magic
    
(sethi 0x40000, %g0)
Setting new inspection cpu: cpu1
simics> c

This used to work with GEMS 1.3 and Simics
          
2.2.19.
    
      
          
Is
    
        
there any ideas why it doesn't work with Simics
3.0.22?

Thanks a lot!


--- Dan Gibson <degibson@xxxxxxxx> wrote:

  
      
          
Use the -stall option on the simics command
            
line.
    
Dave Z. wrote:

    
        
            
Hi, 

Is the following problem not a GEMS issue?

Thanks,

Dave

----- Original Message ----
From: Dave Z. <zhu_dave@xxxxxxxxx>
To: gems Users <gems-users@xxxxxxxxxxx>
Sent: Tuesday, November 21, 2006 11:57:21 AM
Subject: [Gems-users] ruby results

Hi,

I've upgraded my Simics version to 3.0.22.
      
          
              
Everything
    
        
            
seems to work fine except for the Ruby
              
results.
    
          
              
I'm
    
        
not sure if this is a GEMS problem, but the
          
              
results
    
        
      
          
              
I
    
        
            
get regarding the memory requests (misses,
      
          
              
coherence
    
        
            
events, etc.) are all zero. After reading my
checkpoint, I do the following:

instruction-fetch-mode instruction-fetch-trace
istc-disable
dstc-disable
cpu-switch-time 1
magic-break-enable
load-module ruby
ruby0.init

The only thing different from my old
          
              
configuration
    
        
      
          
              
is
    
        
            
that I get a warning info as follows:

[cpu0 info] Note that on this cpu,
instruction-fetch-trace is implemented using
instruction-cache-access-trace with a suitable
      
          
              
cache
    
        
            
line size.
[cpu1 info] Note that on this cpu,
instruction-fetch-trace is implemented using
instruction-cache-access-trace with a suitable
      
          
              
cache
    
        
            
line size.

The Simics folks say that it's a harmless info
      
          
              
message
            
=== message truncated ===



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
_______________________________________________
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→]