Re: [Gems-users] IFETCHs and the store buffer

[Dan Gibson <degibson@xxxxxxxx>]

Rubén,

It is not *incorrect* to snoop the store buffer on an IFETCH, since values in store buffers are, technically, retired state, but I agree its not a very likely design point to actually be implemented -- especially considering ICaches are typically not coherent.

Regards,
Dan

Rubén Titos wrote:

Hi everyone,

Taking a look at doRequest in ruby/system/Sequencer.C, I just came across this code that totally confused me (after the fast path checking). Assuming TSO consistency, the store buffer is checked to see if the load (LD) can be entirely satisfied from it. Since Sequencer::makeRequest is the only one that inserts into the store buffer (by calling insertStore), and it does so only with writes (ST, ST_XACT, LOG_ST, LDX_XACT, ATOMIC), why are IFETCHs also meaningful here?

Cheers,

Rubén

______

bool Sequencer::doRequest(const CacheMsg& request) {

  // Check the fast path
[...]

  if (TSO && (request.getType() == CacheRequestType_LD || request.getType() == CacheRequestType_IFETCH)) {

    // See if we can satisfy the load entirely from the store buffer
    SubBlock subblock(line_address(request.getAddress()), request.getSize());
    if (m_chip_ptr->m_L1Cache_storeBuffer_vec[m_version]->trySubBlock(subblock)) {
      DataBlock dummy;
      hitCallback(request, dummy, GenericMachineType_NULL);  // Call with an 'empty' datablock, since the data is in the store buffer
      return true;
    }
  }

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.