Revalidated the ATCM handler result across four placements, and it holds - #632
Merged
fdesbiens merged 1 commit intoAug 17, 2026
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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_inlineimplementation, so the placements cannot drift apart as the handler is edited. The timing wrapper stays in.textin 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.