Skip to content

Revalidated the ATCM handler result across four placements, and it holds - #632

Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:feature/r52-s32z280-revalidate-atcm
Aug 17, 2026
Merged

Revalidated the ATCM handler result across four placements, and it holds#632
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:feature/r52-s32z280-revalidate-atcm

Conversation

@fdesbiens

Copy link
Copy Markdown
Contributor

The handler comparison in #630 measured a single alignment — the same mistake that made this example's cache benchmark report 24% or 0% for identical silicon, and that invalidated a defect report to NXP. #631 fixed the cache probe; this applies the same treatment to the handler measurement and re-checks the ATCM claim under it.

The claim survives

Mean cycles for the handler body, four placements at different offsets within a cache line:

loop offset in line code RAM ATCM
0 523 383
16 534 377
32 539 375
48 521 383

ATCM is faster at every placement, by about 28%, and the two sets of means do not overlap. Worst case improves as well: 510 against 694.

Two things worth recording beyond the headline

The handler measurement is only mildly alignment-sensitive — 3.5% across placements in code RAM, 2% in ATCM — quite unlike the cache loop's two clean modes. So this comparison was less fragile than the cache one, and #630's direction was right even though its method was not defensible. Absolute numbers differ from #630 because the body now sits behind a placement wrapper that adds a call; the comparison is internally consistent either way.

Both variants report identical cache sweeps (0, 0, 240, 240), which settles the apparent regression that this branch's predecessor showed. That was the single-alignment probe moving between its two modes, not anything about ATCM. Worth stating explicitly, because I reported it as an ATCM regression at the time and it was not.

Method

One copy of the logic is kept. The four wrappers inline a single always_inline implementation, so the placements cannot drift apart as the handler is edited. The timing wrapper stays in .text in both variants, so its own cost appears in every sample and cancels.

Samples are taken in blocks of 16 per placement rather than interleaved, so each alignment is measured under steady conditions.

Verification

All three S32Z280 targets build clean with no warnings. Both images pass six of six boot probes.

The handler comparison in eclipse-threadx#630 measured one alignment, which is the mistake
that made the cache benchmark in this example report 24% or 0% for identical
silicon. The handler body is now generated at four offsets within a cache
line, all four are measured, and the figures are reported per placement.

The claim survives. Mean cycles for the handler body:

    loop offset      code RAM    ATCM
    0                     523     383
    16                    534     377
    32                    539     375
    48                    521     383

ATCM is faster at every placement, by about 28%, and the two sets of means do
not overlap. Worst case improves as well, 510 against 694.

Two things worth recording beyond the headline.

The handler measurement is only mildly alignment sensitive, 3.5% across
placements in code RAM and 2% in ATCM, quite unlike the cache loop's two
modes. So this comparison was less fragile than the cache one, and eclipse-threadx#630's
direction was right even though its method was not defensible. The absolute
numbers differ from eclipse-threadx#630 because the body now sits behind a placement wrapper
that adds a call; the comparison is internally consistent either way.

Both variants also report identical cache sweeps, 0 and 0 and 240 and 240,
which settles the regression this branch's predecessor appeared to show. That
apparent regression was the single-alignment probe moving between its two
modes, not anything about ATCM.

One copy of the logic is kept: the wrappers inline a single always_inline
implementation, so the four placements cannot drift apart.

Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
@fdesbiens
fdesbiens merged commit 3aaaa67 into eclipse-threadx:dev Aug 17, 2026
4 checks passed
@fdesbiens
fdesbiens deleted the feature/r52-s32z280-revalidate-atcm branch August 17, 2026 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant