By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), August 22, 2012 9:19 am
Room: Moderated Discussions
One could avoid adding complexity to the store queue by using an external filter. Hits in the filter could snoop the store queue at a lower priority than internal load and store operations or simply abort the transaction (even if the address is not in the store queue). (Replicating the store queue address fields would effectively be generating a perfect filter and could be less risky than sharing the store queue.) One might also be able to exploit the cache (and miss status handling registers, if they are snooped) to partially filter accesses (Since this could generate false positives--a cache hit that is not a LSQ hit--and false negatives--a cache miss that is a LSQ hit--, some additional handling would be desirable.).
It might also be noted that the mechanism to support cache-based transactional memory could also be used to extend speculation depth. A checkpoint register set could be provided to retain register values for a potential rollback. (This register set could aggressively support banking and use shared read-write ports. It could even be relatively slow compared to the main register set. Any rollback might be assumed to be a slow and hopefully rare event anyway.)
It might also be noted that the mechanism to support cache-based transactional memory could also be used to extend speculation depth. A checkpoint register set could be provided to retain register values for a potential rollback. (This register set could aggressively support banking and use shared read-write ports. It could even be relatively slow compared to the main register set. Any rollback might be assumed to be a slow and hopefully rare event anyway.)
Topic | Posted By | Date |
---|---|---|
Article: Haswell TM Alternatives | David Kanter | 2012/08/21 09:17 PM |
Article: Haswell TM Alternatives | Håkan Winbom | 2012/08/21 11:52 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 01:06 AM |
Article: Haswell TM Alternatives | anon | 2012/08/22 08:46 AM |
Article: Haswell TM Alternatives | Linus Torvalds | 2012/08/22 09:16 AM |
Article: Haswell TM Alternatives | Doug S | 2012/08/24 08:34 AM |
AMD's ASF even more limited | Paul A. Clayton | 2012/08/22 09:20 AM |
AMD's ASF even more limited | Linus Torvalds | 2012/08/22 09:41 AM |
Compiler use of ll/sc? | Paul A. Clayton | 2012/08/28 09:28 AM |
Compiler use of ll/sc? | Linus Torvalds | 2012/09/08 12:58 PM |
Lock recognition? | Paul A. Clayton | 2012/09/10 01:17 PM |
Sorry, I was confused | Paul A. Clayton | 2012/09/13 10:56 AM |
Filter to detect store conflicts | Paul A. Clayton | 2012/08/22 09:19 AM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 02:02 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 02:45 PM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 09:56 PM |
Cache line granularity? | Paul A. Clayton | 2012/08/28 09:28 AM |
Cache line granularity? | David Kanter | 2012/08/31 08:13 AM |
A looser definition might have advantages | Paul A. Clayton | 2012/09/01 06:29 AM |
Cache line granularity? | rwessel | 2012/08/31 07:54 PM |
Alpha load locked granularity | Paul A. Clayton | 2012/09/01 06:29 AM |
Alpha load locked granularity | anon | 2012/09/02 05:23 PM |
Alpha pages groups | Paul A. Clayton | 2012/09/03 04:16 AM |
An alternative implementation | Maynard Handley | 2012/11/20 09:52 PM |
An alternative implementation | bakaneko | 2012/11/21 05:52 AM |
Guarding unread values? | Paul A. Clayton | 2012/11/21 08:39 AM |
Guarding unread values? | bakaneko | 2012/11/21 11:25 AM |
TM granularity and versioning | Paul A. Clayton | 2012/11/21 08:27 AM |
TM granularity and versioning | Maynard Handley | 2012/11/21 10:52 AM |
Indeed, TM (and coherence) has devilish details (NT) | Paul A. Clayton | 2012/11/21 10:56 AM |