Files
Sylpheed/tools/ppc-manual/alu/norx.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

4.7 KiB
Raw Blame History

norx — NOR

Category: Integer ALU · Form: X · Opcode: 0x7c0000f8

Assembler Mnemonics

Mnemonic XML entry Flags Description
nor norx NOR
nor. norx Rc=1 NOR

Syntax

nor[Rc] [RA], [RS], [RB]

Encoding

norx — form X

  • Opcode word: 0x7c0000f8
  • Primary opcode (bits 05): 31
  • Extended opcode: 124
  • 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
RS norx: read Source GPR (alias for RD in some stores).
RB norx: read Source GPR.
RA norx: write Source GPR (r0r31).
CR norx: 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

norx

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

Status-Register Effects

  • norx: CR0 ← signed-compare(result, 0) with SO ← XER[SO], when Rc=1.

Operation (pseudocode)

RA <- ~((RS) | (RB))

C Translation Example

/* C translation: the xenia-rs interpreter arm below in           */
/* Implementation References is the authoritative semantic        */
/* snapshot. Translate it line-by-line:                            */
/*   - ctx.gpr[N]  -> r[N]       (or f[]/v[] for FPRs/VRs)        */
/*   - mem.read_u*/write_u* -> mem_read_u*_be / mem_write_u*_be   */
/*   - ctx.update_cr_signed(fld, v) -> update_cr_signed(fld, v)   */
/*   - ctx.xer_ca / xer_ov / xer_so -> xer.CA / xer.OV / xer.SO   */
/* The Register Effects and Status-Register Effects tables above  */
/* enumerate every side effect a faithful translation must emit.  */

Implementation References

norx

xenia-rs interpreter body (frozen snapshot)
        PpcOpcode::norx => {
            // PPCBUG-029: `not` simplified mnemonic — every `not` poisoned the GPR.
            let rs32 = ctx.gpr[instr.rs()] as u32;
            let rb32 = ctx.gpr[instr.rb()] as u32;
            ctx.gpr[instr.ra()] = (!(rs32 | rb32)) as u64;
            if instr.rc_bit() { ctx.update_cr_signed(0, ctx.gpr[instr.ra()] as u32 as i32 as i64); }
            ctx.pc += 4;
        }

Special Cases & Edge Conditions

  • RA ← ~(RS OR RB). Bit-wise NOR. The canonical idiom for one-instruction NOT: not RA, RS is the simplified mnemonic for nor RA, RS, RS — both source operands the same yields ~RS. Almost every disassembly contains this pattern.
  • Operand convention is X-form (RA destination, RS/RB sources).
  • 64-bit operation on Xenon; full 64-bit complement via ! on u64.
  • No OE or XER side effects.
  • Rc=1 CR0 update truncates to 32 bits in xenia-rs. interpreter.rs:372 uses as i32 as i64. Note that NOR almost always produces results with high bits set (since the OR rarely covers all 64 bits), so the truncated CR0 is usually LT (negative low half) where spec might give a different signed compare for the full 64-bit value.
  • nor. after a clear-low operation is a common pattern for testing whether some high-bit mask is empty.

IBM Reference