Review Board 2.0.15


O3: Support squashing all state after special instruction

Review Request #320 - Created Nov. 19, 2010 and submitted

Information
Ali Saidi
gem5
Reviewers
Default 
O3: Support squashing all state after special instruction

For SPARC ASIs are added to the ExtMachInst. If the ASI is changed simply
marking the instruction as Serializing isn't enough beacuse that only
stops rename. This provides a mechanism to squash all the instructions
and refetch them

   

  


 


 

  

  









  
 


  

 
















 



 

  


 


  



   

   
Gabe Black

   
Posted  (Nov. 20, 2010, 4:30 p.m.)


  


  


  

   
Generally I like it. I'll trust that the actual mechanism in the commit stage is correct. There are some mostly superficial tweaks that need to happen, but then I'm ok with it.



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/arch/sparc/isa/decoder.isa
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
This line is probably too long now.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    fixed
    
    
    
   
    2. 

   


  


    


    

     
     

      

       
        

         
          src/cpu/o3/commit_impl.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Since this is used in only one spot this intermediate variable probably isn't necessary and obfuscates what's going on a bit.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I was trying to be careful about when the instruction was completed and reading it before hand.... It doesn't seem like that was necessary. 
    
    
    
   
    2. 

   


  


    


    

     
     

      

       
        

         
          src/cpu/o3/commit_impl.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
I'm guessing here, but does commit already have code that does this? Do we want to pull that out into a function? Whether or not this sort of thing is already being done (and I can't imagine it's not) this is a nice mostly independent blob of code doing something fairly specific, so it'd be a great candidate to put in a function and simplify this one.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    close, but not quite. The code that that does this for a misspredict or a fault in a bit different. it updates various fields for the current state and squashes the current instruction instead the next one.I'll move the code into a function.
    
    
    
   
    2.