[PTLsim-devel] [BUG][PATCH] Inconsistent arguments to probecache

Sat Nov 10 10:03:16 EST 2007

Hi,
  I think I have found an inconsistency when calling 
ReorderBufferEntry::probecache. issueload calls it with the 
_physical_address (oooexec.cpp, line 1445), but tlbwalk uses the 
virtual address in (oooexec.cpp, line 1545).

Using the virtual address would make more sense, as probecache 
retrieves the physical address again from the LSQEntry and uses the 
addr only for doing statistics, which usually contain virtual 
addresses.

I hence propose to change the call to probe_cache in issueload to:

probecache(addr, sfra);

I'm actually glad that I'm not the only one who is confused by the 
massive number of different addresses floating around in 
issueload. ;-)

I know, I know, whining about missing comments is not too helpful, but 
I guess a brief hint to the purposes of address parameters and local 
vars is helpful. I have made some hints for that in my code, feel 
free to incorporate and please correct me, if I'm wrong!

oooexec.cpp, probecache:
//
// Probe the cache and initiate a miss if required
// Parameters: addr - effective virtual address, adjusted for 
unaligned loads!
//             sfra - LSQ-entry of aliasing load
//
int ReorderBufferEntry::probecache(Waddr addr, LoadStoreQueueEntry* 
sfra) {

oooexec.cpp, issueload:
  /* SD: There are quite a few addresses in this function:
     state.physaddr - physical address aligned to 8 byte, shifted
     right by 3
     physaddr       - physical address, not shifted
     addr           - is the effective virtual address, adjusted for
     unaligned loads of halfs
     origaddr       - effective virtual address, not adjusted for
     unaligned accesses -> value in ROBentry
     mapped         - physical address, mapped to PTLsims address
     space in order to access the data from within the simulator
     virtpage       - same as addr, but stored inside the ROBentry */
  Waddr addr;

Sorry, spacing is a bit off, but I felt a proper patch wouldn't be 
appropriate here.

Again, this is what I've figured out. Please let me know if I'm wrong 
here, as I strongly depend on some of the findings above.

Thanks,
  Stephan
-- 
Stephan Diestelhorst, AMD Operating System Research Center
stephan.diestelhorst at amd.com, Tel.   (AMD: 8-4903)