Dissecting Conditional Branch Predictors of Apple Firestorm and Qualcomm Oryon for Software Optimization and Architectural Analysis

Jiajie Chen; Peng Qu; YouHui Zhang

REVIEW 4 major objections 5 minor 30 references

Dissecting Conditional Branch Predictors of Apple Firestorm and Qualcomm Oryon for Software Optimization and Architectural Analysis

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper recovers the conditional branch predictor internals of Apple Firestorm and Qualcomm Oryon, revealing a TAGE-style design with split history registers and six pattern history tables.

desk verdict Firestorm CBP reverse engineering is strong and novel; Oryon details are deferred, making the dual-claim paper conditional. read the letter →

arxiv 2411.13900 v1 pith:T5A7NUGS submitted 2024-11-21 cs.AR

Jiajie Chen , Peng Qu , Youhui Zhang This is my paper · ORCID

classification cs.AR

keywords branchpredictorreverseengineeringTAGEAppleFirestormQualcommOryonpathhistoryregisterperformancemonitoringcountermispredictionMPKI

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims to recover, for the first time, the conditional branch predictor (CBP) internals of Apple Firestorm and Qualcomm Oryon, the microarchitectures behind the Apple M1 and Qualcomm X Elite. It identifies a TAGE-style predictor with a 100-bit target-address history register (PHRT), a second branch-address history register (PHRB) that is 28 bits on Firestorm and 32 bits on Oryon, and six pattern history tables with specified history lengths, associativities, index functions, and tag functions. It also discovers previously unpublished performance counters that count only conditional-branch mispredictions, which make the measurements possible. If these results hold, compilers and simulators can model these branch predictors instead of treating them as black boxes, and the paper reports up to 14% MPKI reduction and 7% speedup from two newly described misprediction effects, named Scatter and Annihilation.

What carries the argument

The central object is the split path history register pair (PHRT and PHRB) together with the six pattern history tables of a TAGE-style conditional branch predictor. TAGE is a predictor in which several pattern tables indexed by different history lengths vote, with the longest matching table overriding shorter ones. The paper's key mechanism is differential bit injection: instead of clearing the PHR to zero, it injects a single known bit difference into the history through indirect branches and observes conditional-branch mispredictions through newly discovered conditional-only performance counters. This allows each PHR bit, PC input bit, index bit, and tag bit to be located one XOR relationship at a time, without assuming a simple index organization or a clearable history register.

What would settle it

Run an indirect-branch-only workload on a Qualcomm X1E-80-100 and read counter 0x400; if it increments, the counter is not conditional-only and the inference chain collapses. Similarly, on Apple M1, if counter 0xc5 increments during an indirect-branch-only loop, the conditional-only assumption fails and the PHR-length measurement breaks.

Watch

Extended reading notes

Core claim

The paper's central discovery is that the Firestorm and Oryon CBPs are TAGE-like predictors that keep branch history in two separate shift registers rather than one combined path history register. The first register, PHRT, is 100 bits wide and updates as PHRT_new = (PHRT_old << 1) XOR T[31:2]; the second, PHRB, is 28 bits on Firestorm and 32 bits on Oryon and updates as PHRB_new = (PHRB_old << 1) XOR B[5:2]. Each taken branch shifts both registers by one bit and XORs in the footprint, and only bits B[5:2] of the branch address and T[31:2] of the target address enter the footprint. The paper lists six pattern history tables for each core, with their history lengths, associativities, and capacities, and shows that Oryon's total inferred CBP size matches Qualcomm's announced 80 KB figure. It also recovers the index and tag functions of each table, which combine selected PHRT, PHRB, and PC bits through XOR operations, and uses these models to explain the Scatter and Annihilation effects that increase misprediction rates.

Load-bearing premise

The recovered structures are measured through performance counters that the paper assumes count only conditional-branch mispredictions; if those counters also count indirect-branch or other front-end mispredictions during the injection microbenchmarks, every inferred history length and index/tag bit could be wrong.

Editorial extensions

If this is right

Software can now simulate the Firestorm and Oryon CBPs exactly enough to attribute mispredictions to specific branches and PHT entries, enabling root-cause optimization instead of heuristic tuning.
The Scatter effect implies that inserting a single NOP at a tag-sensitive location can cut mispredictions materially, as demonstrated by a 7% speedup on Oryon and 6% on Intel Cascade Lake.
The Annihilation effect implies that CBP designers should include lower bits of both branch and target addresses in the PHR footprint to reduce history collisions.
The cross-vendor comparison indicates that CBP capacity, not the fine details of hash functions, dominates MPKI, so future designs may trade hash complexity for larger tables.
Partitioning a PHT by one PC bit allows two adjacent conditional branches to be predicted per cycle from a single SRAM access, matching the observed Intel, Apple, and Qualcomm designs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The differential-injection pipeline, including hidden-counter discovery, likely transfers to other undocumented out-of-order ARM cores, as long as any conditional-branch-only counter can be found or inferred.
The recovered index and tag formulas could enable more precise side-channel or branch-target-injection studies on these cores, a direction the paper does not explore.
The Scatter result suggests an automated compiler pass could simulate CBP tag behavior and choose NOP placements or branch reorderings to minimize PHT conflicts, rather than relying on manual inspection.
The split PHR design raises a question about speculative update and recovery cost that the paper leaves open; a quantitative study of that cost on real hardware would be a natural extension.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the take: this is the first credible public reverse engineering of Apple Firestorm's conditional branch predictor, and the methodology is a real step beyond Half&Half. The Oryon half of the claim is real but not fully supported in the manuscript—the detailed results are deferred to an unspecified online location, and several PHT entries in Table 3 are marked low confidence. So treat the paper as a strong Firestorm study with an Oryon promise.

What's new: the pipeline uses indirect branches to inject PHR values without contaminating the conditional misprediction counter, uses a differential approach to avoid needing to clear the PHR, and recovers tag before index. That's a legit generalization. The hidden PMC discovery on Oryon (0x400) is useful. The Scatter and Annihilation effects are documented with microbenchmarks; the NOP insertion giving 7% speedup on Oryon and 2% on Firestorm is a concrete, falsifiable result. The Firestorm model itself—100-bit PHRT, 28-bit PHRB, six PHTs with specific index/tag functions—is detailed and internally consistent. The comparison across Intel/Apple/Qualcomm under the ChampSim-like simulator is a nice touch, even if capacity dominates.

Soft spots: First, the Oryon results. Section 3.5 says 'we primarily present Firestorm results... and we will publish the full results online.' No URL, no artifact. That means the central claim 'recover the CBPs of Apple Firestorm and Qualcomm Oryon' is only half-checkable. Table 3 marks several Oryon rows low confidence, and the Oryon index/tag functions are absent. This is a missing-support problem, not a demonstrated error, but it is load-bearing. Second, no error bars or run-to-run variance anywhere; the cliff in Figure 4 (0% to 50% at 100 vs 101 branches) is suspiciously clean. Third, the Scatter and Annihilation explanations are post hoc. They are consistent with the model, but the model is also used to explain them, so there's a mild self-reference. The NOP optimization is empirical and separate, so I don't see equation-level circularity, but the paper could be more careful about presenting the effects as hypotheses rather than confirmed mechanisms.

Who benefits: compiler engineers, security researchers, and anyone doing microarchitectural side-channel analysis. The Firestorm model alone is worth the read. A serious referee should engage, but should request the Oryon supplement or a revision that includes at least the Oryon PHT functions in the paper.

Recommendation: accept for peer review. The Firestorm contribution is substantial and the methodology is sound enough to warrant referee time. The Oryon gaps are addressable.

Referee Report

4 major / 5 minor

Summary. The paper presents a revised reverse-engineering pipeline for conditional branch predictors and applies it to Apple Firestorm and Qualcomm Oryon. It claims to recover a 100-bit PHRT, a 28-bit (Firestorm) or 32-bit (Oryon) PHRB, and six TAGE-like PHTs with the history lengths, associativities, and index/tag functions summarized in Table 3. The authors also report previously undisclosed PMCs (0xc5 on Firestorm and 0x400 on Oryon) that isolate conditional-branch mispredictions, identify two effects ('Scatter' and 'Annihilation') that degrade prediction accuracy, propose a NOP-insertion optimization that yields up to 14% MPKI reduction and 7% speedup on Oryon, and compare the recovered CBPs with Intel Skylake and Alder Lake in a common simulator.

Significance. If the recovered structures are correct, this is the first detailed disclosure of the conditional branch predictors in two major recent microarchitectures, and it would be of real value to compiler writers, performance engineers, and security researchers. The paper has several genuine strengths: the differential microbenchmarks avoid the strong PHR-clearing assumption of prior work, the hidden-PMC discovery is an independent contribution, and the measured NOP-optimization effect is a concrete, falsifiable result that does not depend on the correctness of the model. The unified simulator comparison, while preliminary, is a useful step toward cross-vendor CBP analysis. However, the paper is not fully self-contained: the Oryon index/tag functions are deferred to an unspecified online resource, and several PHT rows are explicitly marked low confidence. These gaps are load-bearing because the central claim is the recovery of exact structures.

major comments (4)

[Section 3.5, Contributions] The manuscript states that 'we primarily present Firestorm results in the following paragraphs and we will publish the full results online,' but no URL, repository, or artifact identifier is given anywhere. As a result, the Oryon PHT index and tag functions appear only as the column totals in Table 3, and even those are marked low confidence for Oryon PHTs 5 and 6. Because the first contribution claims recovery of the Oryon CBP, the Oryon half of the central claim is not checkable from the submitted manuscript. Please include the full Oryon recovery results (index/tag functions for all six PHTs) or explicitly reduce the claim to Firestorm only.
[Section 3.3, Tables 1 and 2] The identification of 0xc5 on Firestorm and 0x400 on Oryon as conditional-branch misprediction counters rests on only three microbenchmarks with expected values n/2, 0, and n/2. The paper does not report run-to-run variance, boundary behavior, or checks for contamination from indirect-branch mispredictions, return mispredictions, or other front-end events. Since every downstream measurement (PHR length, footprint bits, PHT index/tag functions) is filtered through this counter, an undetected contamination source would systematically bias the recovered parameters. Please add validation experiments with mixed branch types, varied branch frequencies, and repeated runs with reported confidence intervals.
[Section 3.6 and Table 3] The recovery of PHTs 2–6 is described only briefly, and the history lengths in Table 3 (e.g., 57, 32, 18, 11, 6 for Firestorm) are asserted without the supporting microbenchmark evidence. In particular, the statement that 'to recover the 2nd PHT of Firestorm, which uses 57 bits of PHRT' appears to presuppose the quantity that the procedure is supposed to determine. Please explain how each history-length boundary was identified without prior knowledge of it, and provide the recovered index/tag equations for all six PHTs, or clearly mark which values remain provisional. The asterisked rows are not sufficient support for the exact-structure claim.
[Section 4.1.2] The Scatter explanation is not quantitatively established. The text asserts that inserting a NOP between .L2 and .L3 makes the two critical branches' PHT tag contributions differ by only one bit, but it does not actually compute the tag/index values for the configurations in Table 4 using the recovered Oryon model, nor does it show that the model predicts the measured direction and magnitude of the MPKI change. Since the optimization itself is measured separately, this is not a circularity issue, but the 'root cause' claim needs a direct model-level demonstration, such as a simulated MPKI comparison with and without the NOP under the recovered Oryon CBP.

minor comments (5)

[Listing 1] The comment 'how many taken branches an be tracked' contains a typo; it should read 'can be tracked'.
[Figures 4–8] The figures appear to show single measurement runs without error bars or confidence intervals. Given the differential nature of the microbenchmarks, a small number of repeated runs would make the reported thresholds and bit positions considerably more convincing.
[Table 3] The header labels 'PHRT' and 'PHRB' do not indicate that the numeric values are history lengths in bits; please clarify, and also state whether the '# Index bits' column includes the associativity bits.
[Section 3.5.2] The axis label 'Log2 branch base address' in Figure 7 is ambiguous; clarify whether the base address is the start address of a block of conditional branches and how the cases 2^3 through 2^19 were generated.
[Section 5.1.1] The text states that the simulator 'aligns with a commercial processor' but gives no validation of modeled MPKI against hardware-measured MPKI for the same workloads. A brief validation table would substantially strengthen the comparison in Figure 9.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the CBP parameters are measured from independent microbenchmarks, and the Scatter/Annihilation analyses use the recovered model to explain separate observations rather than to fit it.

full rationale

The derivation chain is an empirical reverse-engineering pipeline: hidden PMCs are validated on microbenchmarks with known misprediction counts (Table 1), the PHR length/shift/footprint are measured with correlated-branch probes (Figures 4-6), and the PHT associativities and index/tag bits are recovered by differential injection and set-conflict experiments (Sections 3.5-3.6). None of these steps defines a quantity in terms of the target it later 'predicts'. The Scatter effect is first observed as a NOP-placement effect on binary search (Section 4.1.1) and then explained using the previously recovered Oryon tag function; the Annihilation analysis is a static collision count using the recovered PHR update functions. The MPKI comparisons in Section 5 are simulations on SPEC/Geekbench that do not feed back into the recovered parameters. There is no equation-level identity between an input and an output, no fitted parameter renamed as a prediction, and no load-bearing self-citation: the prior-work citations (Half&Half, TrustZoneTunnel, Google Project Zero) are external and serve as methodology starting points. The manuscript does contain a verifiability limitation, not circularity: Section 3.5 states 'we primarily present Firestorm results in the following paragraphs and we will publish the full results online', and Table 3 marks several PHT rows 'low confidence'; the Oryon-specific index/tag evidence is therefore not fully checkable from the paper alone. This affects substantiation of the Oryon half of the central claim, but it is a missing-support issue rather than a circular derivation, so the circularity score remains 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper's central claims rest on direct measurements obtained through purpose-built microbenchmarks, so there are no fitted free parameters. The structural axioms are the TAGE/PHR model and the integrity of the discovered PMC counters; these are domain assumptions rather than ad hoc inventions.

assumptions (3)

domain assumption The CBP of Firestorm and Oryon is a TAGE-like predictor consisting of set-associative PHTs indexed by PC and PHR bits.
The reverse engineering pipeline (Section 3.1) assumes the TAGE structure and fits observed microbenchmark data to it; if the hardware uses a fundamentally different scheme, the recovered parameters would be artifacts.
domain assumption The hidden PMC counters 0xc5 on Firestorm and 0x400 on Oryon count only conditional branch mispredictions, and the three microbenchmarks in Section 3.3 isolate conditional, indirect, and all branch mispredictions as expected.
Table 1 and Table 2 assume the counters obey the expected arithmetic; the entire reverse engineering chain depends on uncontaminated counters.
domain assumption The PHR update is a shift-XOR with a shift amount of one bit, with PHRT recording T[31:2] and PHRB recording B[5:2].
Section 3.4.2 infers shift amount 1 from Figures 5 and 6; if the shift amount were larger, the 100-branch tracking length would not imply a 100-bit PHR.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Dissecting Conditional Branch Predictors of Apple Firestorm and Qualcomm Oryon for Software Optimization and Architectural Analysis." pith.science (2026). https://pith.science/paper/T5A7NUGS

@misc{pith2026241113900,
  author       = {Pith},
  title        = {Pith review of: Dissecting Conditional Branch Predictors of Apple Firestorm and Qualcomm Oryon for Software Optimization and Architectural Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T5A7NUGS}},
  note         = {Machine review of arXiv:2411.13900}
}

read the original abstract

Branch predictor (BP) is a critical component of modern processors, and its accurate modeling is essential for compilers and applications. However, processor vendors have disclosed limited details about their BP implementations. Recent advancements in reverse engineering the BP of general-purpose processors have enabled the creation of more accurate BP models. Nonetheless, we have identified critical deficiencies in the existing methods. For instance, they impose strong assumptions on the branch history update function and the index/tag functions of key BP components, limiting their applicability to a broader range of processors, including those from Apple and Qualcomm. In this paper, we design a more general branch prediction reverse engineering pipeline that can additionally recover the conditional branch predictors (CBPs) of Apple Firestorm and Qualcomm Oryon microarchitectures, and subsequently build accurate CBP models. Leveraging these models, we uncover two previously undisclosed effects that impair branch prediction accuracy and propose related solutions, resulting in up to 14% MPKI reduction and 7% performance improvement in representative applications. Furthermore, we conduct a comprehensive comparison of the known Intel/Apple/Qualcomm CBPs using a unified standalone branch predictor simulator, which facilitates a deeper understanding of CBP behavior.

Figures

Figures reproduced from arXiv: 2411.13900 by the authors.

**Figure 1.** Structure of TAGE conditional branch predictor In addition to prediction accuracy, prediction bandwidth is also critical. A simple implementation predicts at most one branch per cycle, making the branch prediction structures easier to implement with low area and high clock frequency. However, many applications execute a large fraction of branches, such as loops with small bodies, where the frontend can deliver at … view at source ↗

**Figure 2.** The procedure of CBP and reverse engineering it Based on this high-level procedure, existing branch prediction reverse engineering works [14, 26] construct a reverse engineering pipeline as shown in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Reverse engineering pipeline: our improvements over the existing pipeline • Interference of mispredictions between different branches: Existing methods primarily use conditional branches to set the PHR to known values. However, these branches also contribute to branch mispredictions and introduce noise to the measured performance monitoring counters (PMC). This makes it hard for these methods to deal with complex … view at source ↗

Figures from the paper (6 more)

**Figure 4.** Figure 4: Misprediction rate of the last conditional branch due to different number of branches before it 3.4.2 Locate address bits in PHR. Next, we reverse engineer the update mechanism and bit width of the PHR. We begin by determining the location of the branch address within…

**Figure 6.** Figure 6: Misprediction rate due to different number of dummy branches and target address toggle bit Finally, we recover the footprint computation function of the PHR. Given that we already know the PHR shift amount and bit width, we can convert the maximum number of dummy branc…

**Figure 5.** Figure 5: Misprediction rate due to different number of dummy branches and branch address toggle bit Subsequently, we employ a similar differential approach to identify the target address bits, utilizing the newly discovered hidden PMC. Instead of using a branch pair to inject …

**Figure 7.** Figure 7: Misprediction rate due to different number of conditional branches and log2 of branch base address we can conclude that the 1st PHT of the Firestorm CBP is 4-way set associative and uses PC[6] and PC[9] in its index function. Similarly, we find that the 1st PHT of the …

**Figure 8.** Figure 8: Branch misprediction rate and MPKI due to different NOP insert location on Oryon [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

**Figure 9.** Figure 9 [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 29 canonical work pages

[1]

Accessed on Oct, 2024

Championship branch prediction (cbp-4), 2014. Accessed on Oct, 2024

work page 2014
[2]

Accessed on Oct, 2024

Championship branch prediction (cbp-5), 2016. Accessed on Oct, 2024

work page 2016
[3]

Software optimization guide for amd epyc™ 7002 processors,

AMD. Software optimization guide for amd epyc™ 7002 processors,

work page
[4]

Software optimization guide for amd epyc™ 7003 processors,

AMD. Software optimization guide for amd epyc™ 7003 processors,

work page
[5]

Software optimization guide for amd family 17h processors,

AMD. Software optimization guide for amd family 17h processors,

work page
[7]

Software optimization guide for the amd zen5 microarchitecture,

AMD. Software optimization guide for the amd zen5 microarchitecture,

work page
[8]

Arm architecture reference manual armv8 for armv8-a archi- tecture profile, 2024

ARM. Arm architecture reference manual armv8 for armv8-a archi- tecture profile, 2024. Accessed on Oct, 2024

work page 2024
[9]

Software optimization guide for the amd zen4 microarchitecture,

AMD. Software optimization guide for the amd zen4 microarchitecture,

work page

Show all 30 references

[10]

Amd zen 2 microarchitecture analysis: Ryzen 3000 and epyc rome, 2019

Ian Cutress. Amd zen 2 microarchitecture analysis: Ryzen 3000 and epyc rome, 2019. Accessed on Oct, 2024

2019
[11]

Gratz, Daniel A

Nathan Gober, Gino Chacon, Lei Wang, Paul V. Gratz, Daniel A. Jimenez, Elvira Teran, Seth Pugsley, and Jinchun Kim. The Champi- onship Simulator: Architectural Simulation for Education and Com- petition. arXiv preprint arXiv:2210.14324, 2022

arXiv
[12]

Evolution of the samsung exynos cpu microarchitecture

Brian Grayson, Jeff Rupley, Gerald Zuraski Zuraski, Eric Quinnell, Daniel A Jiménez, Tarun Nakra, Paul Kitchin, Ryan Hensley, Edward Brekelbaum, Vikas Sinha, et al. Evolution of the samsung exynos cpu microarchitecture. In 2020 ACM/IEEE 47th Annual International Symposium on C...

2020
[13]

https://www.geekbench.com/blog/2019/09/geekbench- 5/, 2019

Primate Labs. https://www.geekbench.com/blog/2019/09/geekbench- 5/, 2019. Accessed on Oct, 2024

2019
[14]

Kistowski

James Bucek, Klaus-Dieter Lange, and Jóakim v. Kistowski. Spec cpu2017: Next-generation compute benchmark. In Companion of the 2018 ACM/SPEC International Conference on Performance Engineer- ing, ICPE ’18, page 41–42, New York, NY, USA, 2018. Association for Computing Machinery

2018
[15]

Combining branch predictors

S McFarling. Combining branch predictors. Technical report, Citeseer, 1993

1993
[16]

Dynamic path-based branch correlation

Ravi Nair. Dynamic path-based branch correlation. In Proceedings of the 28th annual international symposium on Microarchitecture , pages 15–23. IEEE, 1995

1995
[17]

Branch target buffer organizations

Arthur Perais and Rami Sheikh. Branch target buffer organizations. In Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, pages 240–253, 2023

2023
[18]

Using simpoint for accurate and effi- cient simulation

Erez Perelman, Greg Hamerly, Michael Van Biesbrouck, Timothy Sherwood, and Brad Calder. Using simpoint for accurate and effi- cient simulation. ACM SIGMETRICS Performance Evaluation Review , 31(1):318–319, 2003

2003
[19]

Indirector: {High- Precision} branch target injection attacks exploiting the indirect branch predictor

Luyi Li, Hosein Yavarzadeh, and Dean Tullsen. Indirector: {High- Precision} branch target injection attacks exploiting the indirect branch predictor. In 33rd USENIX Security Symposium (USENIX Secu- rity 24), pages 2137–2154, 2024

2024
[20]

Analysis of the o-geometric history length branch predictor

Andre Seznec. Analysis of the o-geometric history length branch predictor. In 32nd International Symposium on Computer Architecture (ISCA’05), pages 394–405, 2005

2005
[21]

A case for (partially) tagged geomet- ric history length branch prediction

André Seznec and Pierre Michaud. A case for (partially) tagged geomet- ric history length branch prediction. The Journal of Instruction-Level Parallelism, 8:23, 2006

2006
[22]

A study of branch prediction strategies

James E Smith. A study of branch prediction strategies. In 25 years of the international symposia on Computer architecture (selected papers) , pages 202–215, 1998

1998
[23]

The reduction of branch instruction execution overhead using structured control flow

Robert G Wedig and Marc A Rose. The reduction of branch instruction execution overhead using structured control flow. In Proceedings of the 11th annual international symposium on Computer architecture , pages 119–125, 1984

1984
[24]

The o-gehl branch predictor.The 1st JILP Championship Branch Prediction Competition (CBP-1) , 2004

Andre Seznec. The o-gehl branch predictor.The 1st JILP Championship Branch Prediction Competition (CBP-1) , 2004

2004
[25]

Trustzonetunnel: A cross-world pattern history table-based microarchitectural side- channel attack

Tianhong Xu, Aidong Adam Ding, and Yunsi Fei. Trustzonetunnel: A cross-world pattern history table-based microarchitectural side- channel attack. In 2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , pages 01–11. IEEE, 2024

2024
[26]

Half&half: Demystifying intel’s directional branch predictors for fast, secure partitioned execution

Hosein Yavarzadeh, Mohammadkazem Taram, Shravan Narayan, Deian Stefan, and Dean Tullsen. Half&half: Demystifying intel’s directional branch predictors for fast, secure partitioned execution. In 2023 IEEE Symposium on Security and Privacy (SP) , pages 1220–1237. IEEE, 2023

2023
[27]

Alternative implementations of two-level adaptive branch prediction

Tse-Yu Yeh and Yale N Patt. Alternative implementations of two-level adaptive branch prediction. ACM SIGARCH Computer Architecture News, 20(2):124–134, 1992

1992
[28]

Reading privileged memory with a side-channel,

Google Project Zero. Reading privileged memory with a side-channel,
[29]

Snapdragon x elite qualcomm oryon cpu: Design & architecture overview

Gerard Williams. Snapdragon x elite qualcomm oryon cpu: Design & architecture overview. In HCS, 2024

2024
[2018]

Accessed on Oct, 2024. 12

2024
[2024]

Accessed on Oct, 2024

2024

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

Accessed on Oct, 2024

Championship branch prediction (cbp-4), 2014. Accessed on Oct, 2024

work page 2014

[2] [2]

Accessed on Oct, 2024

Championship branch prediction (cbp-5), 2016. Accessed on Oct, 2024

work page 2016

[3] [3]

Software optimization guide for amd epyc™ 7002 processors,

AMD. Software optimization guide for amd epyc™ 7002 processors,

work page

[4] [4]

Software optimization guide for amd epyc™ 7003 processors,

AMD. Software optimization guide for amd epyc™ 7003 processors,

work page

[5] [5]

Software optimization guide for amd family 17h processors,

AMD. Software optimization guide for amd family 17h processors,

work page

[6] [7]

Software optimization guide for the amd zen5 microarchitecture,

AMD. Software optimization guide for the amd zen5 microarchitecture,

work page

[7] [8]

Arm architecture reference manual armv8 for armv8-a archi- tecture profile, 2024

ARM. Arm architecture reference manual armv8 for armv8-a archi- tecture profile, 2024. Accessed on Oct, 2024

work page 2024

[8] [9]

Software optimization guide for the amd zen4 microarchitecture,

AMD. Software optimization guide for the amd zen4 microarchitecture,

work page