Files
Sylpheed/tools/ppc-manual/memory/dcbf.md
sim 84856fc081
All checks were successful
CI / Native — linux (pull_request) Successful in 2h1m57s
CI / WASM — Web (pull_request) Successful in 28m8s
CI / Formatting (pull_request) Successful in 1m26s
docs(ppc-manual): check every xenia-rs claim against Canary's source
The hand-written parts of the manual still described how the retired
xenia-rs interpreter behaved: its snapshots, Rust casts and helpers. Each of
those 490 statements is now either restated as what Canary's emitters and
x64 backend actually do (at the pinned canary_experimental commit), or
dropped where it only made sense for xenia-rs.

Checking them turned up claims that were wrong, not just outdated:

- VSCR[SAT] is never modelled in Canary (DID_SATURATE is a stub and mfvscr
  cannot see it); the pages said saturating ops set it stickily.
- Canary does not implement lswi/lswx/stswi/stswx, dcbi, mtfsb0/mtfsb1,
  vmsum*, vmhaddshs, vupkhpx/vupklpx, and most SPRs; pages described them
  as working.
- Traps evaluate TO in Canary; stvebx/stvehx/stvewx store one element, not
  16 bytes; mtmsrd writes only EE; fres/frsqrte/vrsqrtefp precision claims
  and the stfs "rounds under RN / sets FPSCR" claim contradicted the spec.
- Reservations are a 64 KiB block bitmap plus a value compare, not
  per-address tracking.

Claims that neither Canary's source nor a public spec settles are marked
unverified (NI at boot, vmaddcfp128 operand order, estimate bit-exactness).

Generated regions are untouched; re-running the generator changes nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 21:52:38 +02:00

5.9 KiB
Raw Blame History

dcbf — Data Cache Block Flush

Category: Memory · Form: X · Opcode: 0x7c0000ac

Assembler Mnemonics

Mnemonic XML entry Flags Description
dcbf dcbf Data Cache Block Flush

Syntax

dcbf [RA0], [RB]

Encoding

dcbf — form X

  • Opcode word: 0x7c0000ac
  • Primary opcode (bits 05): 31
  • Extended opcode: 86
  • Synchronising: no
Bits Field Meaning
05 OPCD primary opcode
610 RT/FRT/VRT destination
1115 RA/FRA/VRA source A
1620 RB/FRB/VRB source B
2130 XO extended opcode (10 bits)
31 Rc record-form flag

Operands

Field Role Description
RA0 dcbf: read Source GPR; when the encoded register number is 0 the operand is the literal 64-bit zero, not r0.
RB dcbf: read Source GPR.

Register Effects

dcbf

  • Reads (always): RA0, RB
  • Reads (conditional): none
  • Writes (always): none
  • Writes (conditional): none

Status-Register Effects

No condition-register or status-register effects.

Operation (pseudocode)

; No hand-written pseudocode for this instruction yet.
; The authoritative semantics are the Canary emitter snapshot under
; Implementation References; about half of Canary's emitters open
; with the PPC-style definition as a comment (`RD <- (RA) + (RB)`).
; Every side effect is also enumerated in the Register Effects and
; Status-Register Effects tables above.

C Translation Example

/* No hand-written C yet. Translate the Canary emitter snapshot   */
/* under Implementation References; its HIR maps directly:        */
/*   f.LoadGPR(n) / f.StoreGPR(n, v)  -> r[n] / r[n] = v          */
/*   f.LoadFPR / StoreFPR, f.LoadVR / StoreVR -> f[n], v[n]        */
/*   f.Load(ea, T), f.Store(ea, v) -> raw read / write; emitters   */
/*     wrap them in f.ByteSwap for the big-endian guest value      */
/*   f.UpdateCR(n, v)  -> CR field n from v's LOW 32 BITS vs 0     */
/*   f.LoadCA / f.StoreCA -> xer.CA;  f.StoreSAT -> vscr.SAT       */
/*   i.XO.RA, i.D.DS, ... -> the bit-fields listed under Operands  */
/* The Register Effects and Status-Register Effects tables above  */
/* enumerate every side effect a faithful translation must emit.  */

Implementation References

dcbf

Canary emitter (frozen snapshot @ f21ebd49e9)
int InstrEmit_dcbf(PPCHIRBuilder& f, const InstrData& i) {
  if (!cvars::disable_prefetch_and_cachecontrol) {
    Value* ea = CalculateEA_0(f, i.X.RA, i.X.RB);
    f.CacheControl(ea, 128,
                   CacheControlType::CACHE_CONTROL_TYPE_DATA_STORE_AND_FLUSH);
  }
  return 0;
}

Special Cases & Edge Conditions

  • Flush = write-back + invalidate. If the addressed line is dirty in the data cache, it is written to memory; whether dirty or clean, the line is then removed from the cache. Subsequent loads must refill from memory.
  • Cache line size. Xenon's L1/L2 lines are 128 bytes. The hardware ignores the low seven bits of EA, so dcbf RA, RB flushes the line containing EA regardless of where in that line EA lies. There is no dcbf128 variant — the hint is sized to the architectural line.
  • RA0 semantics. When RA = 0, the base is the literal zero — dcbf 0, RB flushes the line containing address RB. The instruction has no destination register.
  • Canary emits host cache hints only. It keeps no guest-visible cache model: unless the disable_prefetch_and_cachecontrol cvar is set, dcbf becomes a host clflush over the 128-byte cache line (its comment notes Xenon's 128-byte lines), and guest memory is always coherent on the host. This is correct behaviour for an emulator.
  • Unprivileged. dcbf is a problem-state instruction — usable from user code. Storage protection still applies; flushing an unmapped page raises a DSI exception.
  • Pair with sync. Hardware dcbf does not by itself impose ordering; software that needs the flushed data visible to other masters (DMA, GPU) issues a sync afterwards.
  • Self-modifying code companion. When patching code, the recipe is dcbst (push dirty data through to memory) → syncicbi (invalidate I-cache) → isync. dcbf is the heavier alternative when the writer also wants the line out of D-cache.
  • dcbst — write-back without invalidate (lighter than dcbf).
  • dcbi — invalidate without write-back (privileged; loses dirty data).
  • dcbt, dcbtst — touch hints to bring lines in.
  • dcbz, dcbz128 — allocate-and-zero a line.
  • icbi — instruction-cache invalidate, used together for self-modifying code.
  • sync — full memory barrier, typically follows dcbf.

IBM Reference