Review Board 2.0.15


ARM: Fix checkpoint restoration into O3 CPU and the way O3 switchCpu works.

Review Request #620 - Created March 30, 2011 and submitted

Information
Ali Saidi
gem5
Reviewers
Default
ali, gblack, nate, stever 
ARM: Fix checkpoint restoration into O3 CPU and the way O3 switchCpu works.

This change fixes a small bug in the arm copyRegs() code where some registers
wouldn't be copied if the processor was in a mode other than MODE_USER.
Additionally, this change simplifies the way the O3 switchCpu code works by
utilizing TheISA::copyRegs() to copy the required context information
rather than the adhoc copying that goes on in the CPU model. The current code
makes assumptions about the visibility of int and float registers that aren't
true for all architectures in FS mode.

   

  


 


 

  

  









  
 


  

 
















 



 

  


 


  



   

   
Gabe Black

   
Posted  (March 30, 2011, 8:38 a.m.)


  


  


  

   
I'm not sure this is right yet. Won't it only copy the USR registers now and leave out all the other modes? Also, is there anything wrong with reading the CPSR, changing the mode, and then writing it back?



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    No, NumIntRegs is all the registers in the system, not just the user ones. However, if some other register mapping is in effect, the mapping hides the user registers so they can't be accessed. Starting in user mode solves the problem. As far as the CPSR goes, I only want the updateRegMap() functionality, so the no effect versions can't be used and the effect version can change other things (E.g. if you were in thumb mode and cpsr mode was written you the pcstate would be updated). This seems much cleaner. 
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    Ah, ok, so everything that isn't put through the map is flattened to the same thing. That seems a little fragile since if flattening changes it'll break, and it relies on USR mode being identically mapped. I'm not sure exactly what to do about it, though.
    
    
    
   
    3. 


   
  3. 
    
    
     
    
      
     
    
     
    I can't come up with a better solution, but you wrote the initial code that operated that way ;). 
    
    
    
   
    4. 


   
  4. 
    
    
     
    
      
     
    
     
    Honestly I probably copied and pasted that or left it from the original implementation, and since I usually don't pay much attention to the checkpointing/CPU switching stuff just left it that way while I got the other parts working. So you could say it's my fault but not my design.
    
    
    
   
    5. 

   


  




   







    

     
     

      

       
        

         
          src/arch/arm/isa.cc
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Random blank line.