You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like we currently assume that tags have the type Addr, I think this might be undesirable. There are many cases where we need a lot more data than a simple address in a tag. An obvious example is a TLB where the tag may contain things like an ASID, VMID, S/NS, and parts of the address (see for example src/dev/arm/smmu_v3_caches.hh). Similarly, you could imagine BTB entries being tagged with ASID and VMID.
Similarly, I think it would be desirable to not make as many assumptions about the type used lookups. An obvious example of this is the way we currently handle the NS/S bit which ends up being passed separately as a special case. There may well be more of these bits in the future.
It would be a huge improvement if you could make the tag and lookup keys template parameters, but I don't know if this would be feasible in this PR though. It might have a large knock-on effect on the indexing policies.
I think what we need to truly generalise this is a way to specify the following:
A lookup type. This could be a struct or Addr
A hash function that works on the lookup type. Modern caches don't always use the text-book shift and mask approach. This may need to be a parameter.
A comparison operator. In practice, we should probably store the entire lookup type as a tag instead of throwing away bits to save space. This would effectively require an operator== for the lookup type which would just work for many types.
As a concrete example, this would let you define a cache using the following pseudo-code:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
From @andysan (#745 (comment)):
It seems like we currently assume that tags have the type Addr, I think this might be undesirable. There are many cases where we need a lot more data than a simple address in a tag. An obvious example is a TLB where the tag may contain things like an ASID, VMID, S/NS, and parts of the address (see for example src/dev/arm/smmu_v3_caches.hh). Similarly, you could imagine BTB entries being tagged with ASID and VMID.
Similarly, I think it would be desirable to not make as many assumptions about the type used lookups. An obvious example of this is the way we currently handle the NS/S bit which ends up being passed separately as a special case. There may well be more of these bits in the future.
It would be a huge improvement if you could make the tag and lookup keys template parameters, but I don't know if this would be feasible in this PR though. It might have a large knock-on effect on the indexing policies.
I think what we need to truly generalise this is a way to specify the following:
As a concrete example, this would let you define a cache using the following pseudo-code:
You'd then perform lookups using instances of CacheKey.
Beta Was this translation helpful? Give feedback.
All reactions