Files
Sylpheed/tools/ppc-manual/alu/addx.md
MechaCat02 6bdbf89ebc
All checks were successful
CI / Native — linux (pull_request) Successful in 37m56s
CI / WASM — Web (pull_request) Successful in 28m5s
CI / Formatting (pull_request) Successful in 59s
chore(tools): adopt the PPC manual and a canary launcher that works anywhere
CONSOLIDATION.md Phase 6. Both lived untracked in the project root -- on one
disk, backed up by nothing.

  tools/ppc-manual/   393 files, 3.7 MB. 455 instructions, 350 family pages,
                      598 mnemonics resolvable through index.json, plus the
                      generator that produced them.
  tools/run-canary.sh the oracle launcher.

🔴 THE LAUNCHER WAS BROKEN IN TWO WAYS AND IS REWRITTEN, not copied:

  * it pointed at `xenia-rs/sylpheed.iso`, a SYMLINK. Wine cannot resolve one
    and says "path invalid", which reads as a corrupt image rather than a path
    problem -- it has cost a session before. It now points at the real file and
    warns if handed a symlink.
  * it hardcoded one machine's absolute paths, and named `xenia-rs`, which this
    consolidation retires. Now derived from the script's own location, with
    SYLPH_CANARY_BIN / SYLPH_ISO overrides and a check that each exists.

The standing constraints are in its header where someone will read them: one
emulator at a time, Canary runs MUTED, and never judge a crash or a hang from
a Bash-launched run -- a SIGKILL that looked like the binary was the editor's
process supervisor.

⚠️ The manual's GENERATOR reads the xenia-rs source tree, which is going away.
Its decoder now lives here as crates/sylpheed-ppc, so the generator must be
repointed before it is run again. Recorded in the README rather than left for
someone to discover; the manual's content is checked in and regenerates from
nothing implicitly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 21:18:00 +02:00

6.4 KiB
Raw Blame History

addx — Add

Category: Integer ALU · Form: XO · Opcode: 0x7c000214

Assembler Mnemonics

Mnemonic XML entry Flags Description
add addx Add
addo addx OE=1 Add
add. addx Rc=1 Add
addo. addx OE=1, Rc=1 Add

Syntax

add[OE][Rc] [RD], [RA], [RB]

Encoding

addx — form XO

  • Opcode word: 0x7c000214
  • Primary opcode (bits 05): 31
  • Extended opcode: 266
  • Synchronising: no
Bits Field Meaning
05 OPCD primary opcode (31)
610 RT destination GPR
1115 RA source A
1620 RB source B
21 OE overflow-enable flag
2230 XO extended opcode (9 bits)
31 Rc record-form flag

Operands

Field Role Description
RA addx: read Source GPR (r0r31).
RB addx: read Source GPR.
RD addx: write Destination GPR.
OE addx: write (conditional) Overflow-enable bit. When 1, the instruction updates XER[OV] and stickies XER[SO] on signed overflow.
CR addx: write (conditional) Condition-register update. When Rc=1, CR field 0 (or CR6 for vector compares, CR1 for FPU) is updated from the result.

Register Effects

addx

  • Reads (always): RA, RB
  • Reads (conditional): none
  • Writes (always): RD
  • Writes (conditional): OE, CR

Status-Register Effects

  • addx: CR0 ← signed-compare(result, 0) with SO ← XER[SO], when Rc=1.; XER[OV] ← signed-overflow(result); XER[SO] stickies, when OE=1.

Operation (pseudocode)

RT <- (RA) + (RB)

C Translation Example

/* add / add. / addo / addo.  (XO-form)                         */
uint64_t a = r[insn.RA], b = r[insn.RB];
uint64_t result = a + b;
r[insn.RT] = result;
if (insn.OE) { bool ov = (~(a ^ b) & (a ^ result)) >> 63;
               if (ov) { xer.OV = 1; xer.SO = 1; } else xer.OV = 0; }
if (insn.Rc) update_cr0_signed((int64_t)result);

Implementation References

addx

xenia-rs interpreter body (frozen snapshot)
        PpcOpcode::addx => {
            // PPCBUG-012+020: 32-bit ABI writeback truncation + CR0 i32 view.
            let ra32 = ctx.gpr[instr.ra()] as u32;
            let rb32 = ctx.gpr[instr.rb()] as u32;
            let result32 = ra32.wrapping_add(rb32);
            ctx.gpr[instr.rd()] = result32 as u64;
            if instr.oe() {
                let true_sum = (ra32 as i32 as i128) + (rb32 as i32 as i128);
                overflow::apply(ctx, true_sum != (result32 as i32) as i128);
            }
            if instr.rc_bit() {
                ctx.update_cr_signed(0, result32 as i32 as i64);
            }
            ctx.pc += 4;
        }

Extended Pseudocode

RT <- (RA) + (RB)                                ; modulo 2^64, carry discarded
if OE then
    XER[OV] <- (~(RA ^ RB) & (RA ^ RT))[0]       ; signed overflow: same-sign inputs, opposite-sign result
    XER[SO] <- XER[SO] | XER[OV]
if Rc then
    CR0[LT,GT,EQ] <- signed_compare(RT, 0)        ; 64-bit comparison on the Xenon
    CR0[SO]      <- XER[SO]

Special Cases & Edge Conditions

  • No trap on overflow. addo / addo. record overflow in XER[OV] and sticky-set XER[SO]. A trap can only be produced by a separate td/tw instruction examining the result.
  • Signed-overflow predicate. Overflow occurs iff both addends share a sign bit and the result has the opposite sign bit: OV = ((~(a ^ b)) & (a ^ rt)) >> 63. Unsigned carry is not tracked — use addcx when you need XER[CA].
  • XER[SO] is sticky. Once set, it remains set until cleared by mcrxr. The . record forms copy it into CR0[SO].
  • 64-bit CR update on Xenon. The Xbox 360 Xenon CPU is 64-bit, so add. compares the full 64-bit result against zero. Xenia-rs presently truncates to 32 bits before the CR update (result as i32 as i64 in interpreter.rs:95). If your translator must match xenia bit-for-bit, emit a 32-bit compare; if it must be spec-correct, emit a 64-bit compare. Most Xbox 360 object code works either way because results that overflow 32 bits are rare outside of explicit 64-bit math.
  • OE overflow detection not emulated in xenia-rs. The addo / addo. branch in interpreter.rs is a TODO stub. A faithful translator should still emit the overflow check — titles rarely observe XER[OV], but it's occasionally used by profiling / sanity-checking code paths.
  • Operand aliasing. add r3, r3, r3, add r3, r3, r4, add r3, r4, r3 are all legal. The addition reads both source operands before writing RT.
  • No immediate form. For RT = RA + imm use addi / addis. Those are distinct opcodes, not a flag on add.
  • addcx — produces the carry-out in XER[CA].
  • addex — sums (RA) + (RB) + XER[CA] (carry-in chain).
  • addmex, addzex — add to 1 or 0 with carry-in (used to propagate borrows across multiword subtracts).
  • addi, addis — D-form immediate adds; no Rc/OE.
  • addic, addicx — D-form adds that set XER[CA].
  • subfx — the dual: RT ← (RB) (RA).
  • negx — two's-complement negate.

IBM Reference