Review Board 2.0.15


CacheMemory: add allocateVoid() that is == allocate() but no return value.

Review Request #629 - Created March 31, 2011 and submitted

Information
Lisa Hsu
gem5
Reviewers
Default
ali, gblack, nate, stever 
CacheMemory: add allocateVoid() that is == allocate() but no return value.
This function duplicates the functionality of allocate() exactly, except that it does not return
a return value.  In protocols where you just want to allocate a block
but do not want that block to be your implicitly passed cache_entry, use this function.
Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(),
and if you do a dummy assignment Entry foo := cache.allocate(address), the C++
compiler will complain of an unused variable.  This is kind of a hack to get around
those issues, but suggestions welcome.

   

  


 


 

  

  









  
 


  

 


















 

  


 


  




   
Ship it!



   

   
Nilay Vaish

   
Posted  (March 31, 2011, 7:14 a.m.)


  


  


  

   



  

   

   
    
    
   


  





  

 


  

 

















 



 

  


 


  



   

   
Brad Beckmann

   
Posted  (March 31, 2011, 9:15 a.m.)


  


  


  

   
This is more of a question, then a suggestion.  Is there a way to use allocateVoid() a wrapper around allocate() rather than have to duplicate code?  What happens if you cast the return pointer to void?  Does that suppresss the error?  Maybe there is a way to set some attribute on the variable that the compiler can understand.  I have no idea if that is actually possible and if any solution would be portable across compiler generations.  I'm just curious if there was some way to avoid the code duplication.



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Brad, I agree it's kind of ugly and I've never been a fan of code duplication.  (Which reminds me - why do we need two copies of lookup(), one const and one not in CacheMemory?)  I'll try the void * return suggestion, though I wouldn't hold my breath.  I'm open to other suggestions as well, if anyone has any.  I didn't get too creative here.
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    Ok, I think I must have been brain farting.  This patch was the least of my worries, I was more concerned about the ruby-local one, so clearly I didn't even spend an iota of time thinking about this.  I've wrapped allocate() appropriately with no duplication and it works.  Will check in that version.  Must be quitting time :).
    
    
    
   
    3.