Review Board 2.0.15


MEM: TranslatingPorts are replaced with SETranslatingProxys

Review Request #917 - Created Nov. 28, 2011 and discarded

Information
Andreas Hansson
gem5
default
Reviewers
Default
ali, gblack, nate, stever 
MEM: TranslatingPorts are replaced with SETranslatingProxys

This patch introduces the SETranslatingProxy instances replacing the
TranslatingPorts. This requires small chagnes to many files.
Added functionality: Added _parent and systemPort() to SimObject to use for
object loading.
util/regress passing all ignoring failing eio and t1000
Steve Reinhardt
Posted (Dec. 3, 2011, 1:25 a.m.)



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/base/loader/object_file.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Seems weird that we end up with two versions of loadSections() here.  I see that the other one goes away in a later patch, but YA reason why collapsing these might be a good idea.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    The only reason is indeed the transitional phase.
    
    
    
   
    2. 

   


  


    


    

     
     

      

       
        

         
          src/mem/SConscript
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
This is kind of weird... another argument for folding all these patches together.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I agree that merging them is desirable before pushing it into the trunk. The (slightly artificial) split was merely to simplify the review.
    
    
    
   
    2. 

   


  


    


    

     
     

      

       
        

         
          src/python/m5/simulate.py
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
I see what you're doing here, but it's not how I'd do it... if we really want every SimObject to have a system param, we can do that entirely in Python.  There are other reasons why it might be nice to have the parent pointer available in C++, but even then I'm not sure this is the best way to do it.  I'd prefer to just set it up implicitly in createCCObject().




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I have no strong opinions on how it is done and your suggestions make sense. Before going and implementing something I'd prefer to know that everyone is fine with it though.
    
    
    
   
    2. 

   


  


    


    

     
     

      

       
        

         
          src/sim/System.py
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Why does System need to be a MemObject now?  So that it can have a Port?  That seems a little weird, in the sense that the "system" is definitely not an object in the memory system...




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    The system is indeed a MemObject and implements a memory-mapped master interface (i.e. it issues memory requests and gets responses back). The option is to have an object, BigBrother or similar, which has the same functionality. Personally I think it is nicer and cleaner to stick with the system itself being responsible for hanging onto this port.
    
    
    
   
    2.