Files
rk3588-ddr-analysis/benchmark/05_prep_freq_change/GRIND_LOG.md
T
marfrit 282d23fff7 benchmark/05_prep_freq_change: second poll-site function, reference-C only
FUN_0000d10c @ 0xd10c (49 insts) contains poll site 11.
Semantically decoded as a PHY-side prologue for frequency-change
handshake: saves current state of one PHY CTL + four secondary-table
entries, waits for PHY firmware to reach state 1 (idle).

Matching-decomp iteration deferred vs the clean first lift (d328) —
d10c's two-base-pointer csel pattern plus parity-dependent offset
chain gives GCC too much register-allocation freedom. Getting to
>=90% byte-match would be an afternoon of iteration; time better
spent expanding pre-UART coverage breadth.

Poll-site coverage so far:
  d328: sites 12, 13, 14, 15 (C candidate at 89.7% size match)
  d10c: site 11 (reference C only, no matching iteration)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-15 08:14:00 +02:00

2.0 KiB

GRIND_LOG — FUN_0000d10c (second poll-site function)

Status: reference.c only. Matching-decomp iteration deferred — the two-base-pointer csel pattern plus 4 save-and-modify blocks with parity-dependent offsets is too much register-allocation freedom to reach ≥90% byte-match in a single session.

What's here

  • func.bin — raw 196-byte slice, offset 0xd10c..0xd1cf in v1.19
  • func.s — objdumped GNU asm, absolute addresses preserved
  • reference.c — best-effort ground-truth C; semantics inferred from the assembly. Several constants (0x30, 0x4c, 0x1F0000, 0x2FFF0FFF, 0x40000000) remain unnamed pending an AI-Ghidra rename pass.

Why the deferral

This function is the PHY-side prologue of a frequency-change handshake. Compared to FUN_0000d328 (the first lift we did — clean linear PHY-poke sequence):

axis d328 (done) d10c (this one)
instructions 26 49
base pointers used 1 2 (ch_base + sec_table)
csel / conditional moves 0 1 (picks sec_table by ch > 1)
indexed addressing with shift 0 4+ ([x3, x6, LSL #0] etc.)
offset arithmetic tricks offset add once ubfiz + mul + add chains

GCC has too many equally-valid ways to arrange csel plus multi-base address generation. Without ARMCC, byte-match would plateau at ~70% after naive iteration. With objdiff + AI-Ghidra naming + a dedicated afternoon, a good effort would push to 85-90%.

Best next step for this file

  1. AI-Ghidra rename pass (Hermes-2-Pro, GhidrAssist agentic mode) on the constants. Likely auto-names some via tool-call.
  2. Compile reference.c with -Os and count matching insts vs func.s line-by-line — baseline score.
  3. Iterate with restrict-qualified ptrs, __builtin_expect hints, or inline-asm for the csel.

Productive for now: move on. We have poll site 12-15 covered (via d328) and poll site 11 semantically documented. When UART arrives, the equivalent C source exists for the high-value sites — that's what actually matters.