| Deutsch English Français Italiano |
|
<v8eiv4$1qfdi$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Paul A. Clayton" <paaronclayton@gmail.com> Newsgroups: comp.arch Subject: Re: YASV (Yet Another Security Vulnearability) Date: Wed, 31 Jul 2024 19:56:17 -0400 Organization: A noiseless patient Spider Lines: 56 Message-ID: <v8eiv4$1qfdi$1@dont-email.me> References: <v7rqbf$1ta84$1@dont-email.me> <20240725104113.000006e8@yahoo.com> <tJtoO.87238$BYv6.980@fx09.iad> <2024Jul26.181750@mips.complang.tuwien.ac.at> <hFToO.27997$iptd.11865@fx36.iad> <4a5db46ac6e0d485c3303cca4ccdf77e@www.novabbs.org> <v8c509$19dpt$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 01 Aug 2024 01:56:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b3d0f81310faf525501d703443e927ef"; logging-data="1916338"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/faNtz9Z7kmARziZUIpOWtVREdYKZEcLo=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0 Cancel-Lock: sha1:viFZPnfwgIiYE7d0qbir8hCMxlY= In-Reply-To: <v8c509$19dpt$1@dont-email.me> Bytes: 4433 On 7/30/24 9:45 PM, Paul A. Clayton wrote: [snip] > One can also theoretically alter the sense of a prediction state > or the hysteresis by XORing with other data. XORing a hysteresis > bit with one bit derived from the branch address might have a > beneficial effect on interference. (Agree prediction can also > change the sense of a predictor bit. For the hysteresis bit, if > it is not used for a quick confidence estimate, the backward/ > forward character of the static branch could be used to bias the > hysteresis. This might not actually be useful, but is an > obvious design possibility.) I do not know how much such would > affect retraining. Inverting the hysteresis bit sense for half > of the aliasing branches would seem to speed retraining when the > hysteresis is commonly "strongly" (half of aliases would be > interpreted as "weakly") Another possibility would be to use a different indexing function for the hysteresis bits. I was thinking that this might provide a limited benefit similar to gskewed prediction as the hysteresis would usually alias in different branches than the prediction. However, this might increase the destructiveness of aliasing. A strongly taken branch might have a destructive aliaser whose hysteresis is "biased not taken", leading to a change of the prediction. An agreeing hysteresis would not have this weakness as much because most entries would be "strongly agree" not "weakly agree", but that would also mean that hysteresis alias would not be as important. (The unproduced Alpha EV8 used an agree hysteresis and had half as many global 0 table and Meta table hysteresis bits as prediction bits. ["Design Tradeoffs for the Alpha EV8 Conditional Branch Predictor", André Seznec et al., 2002]) An interesting possibility would be is _extra_ mispredictions resulted in choosing a different entry (which applies with meta predictors and other sophisticated predictors). This brings to mind the possibility of having different ways in a TAGE-like predictor use different hashing functions to generate the tag. If a useless entry was available in a set, detection of an alias could move the useful entry into the useless entry that would be less likely to alias in the tag. Swapping entries would allow alias reduction even when all ways in a set have useful entries, but the extra information is missing for one entry. Even victimization would require the way change to be for the dominant branch (e.g., sufficient confidence reduction might trigger the change when the prediction is correct, assuming that the aliasing branch will generally mispredict). I suspect this would be a useless complication, but is seems an interesting possibility. (Rather than swapping, one might just use an extra bit to indicate which hashing function was used for the tag. destructive aliasing might then choose the alternative hashing function. Determining the desired branch to use the entry seems a significant problem.) (At least I find some enjoyment in thinking about such, even if the result is useless and does not inspire a useful thought from someone else.)