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>
6.9 KiB
6.9 KiB
lvx — Load Vector Indexed
Assembler Mnemonics
| Mnemonic | XML entry | Flags | Description |
|---|---|---|---|
lvx |
lvx |
— | Load Vector Indexed |
lvx128 |
lvx128 |
— | Load Vector Indexed 128 |
Syntax
lvx [VD], [RA0], [RB]
lvx128 [VD], [RA0], [RB]
Encoding
lvx — form X
- Opcode word:
0x7c0000ce - Primary opcode (bits 0–5):
31 - Extended opcode:
103 - Synchronising: no
| Bits | Field | Meaning |
|---|---|---|
| 0–5 | OPCD |
primary opcode |
| 6–10 | RT/FRT/VRT |
destination |
| 11–15 | RA/FRA/VRA |
source A |
| 16–20 | RB/FRB/VRB |
source B |
| 21–30 | XO |
extended opcode (10 bits) |
| 31 | Rc |
record-form flag |
lvx128 — form VX128_1
- Opcode word:
0x100000c3 - Primary opcode (bits 0–5):
4 - Extended opcode:
195 - Synchronising: no
| Bits | Field | Meaning |
|---|---|---|
| 0–5 | OPCD |
primary opcode (4) |
| 6–10 | VD128l |
destination low 5 bits |
| 11–15 | RA |
address register |
| 16–20 | RB |
offset register |
| 21–27 | XO |
extended opcode |
| 28–29 | VD128h |
destination high 2 bits |
| 30–31 | — |
reserved |
Operands
| Field | Role | Description |
|---|---|---|
RA0 |
lvx: read; lvx128: read | Source GPR; when the encoded register number is 0 the operand is the literal 64-bit zero, not r0. |
RB |
lvx: read; lvx128: read | Source GPR. |
VD |
lvx: write; lvx128: write | Destination vector register. |
Register Effects
lvx
- Reads (always):
RA0,RB - Reads (conditional): none
- Writes (always):
VD - Writes (conditional): none
lvx128
- Reads (always):
RA0,RB - Reads (conditional): none
- Writes (always):
VD - Writes (conditional): none
Status-Register Effects
No condition-register or status-register effects.
Operation (pseudocode)
EA <- ((RA|0) + (RB)) & ~0xF ; align to 16
VD <- byteswap(MEM(EA, 16))
C Translation Example
/* lvx VD, RA, RB — 16-byte aligned load of a vector register */
uint64_t base = (insn.RA == 0) ? 0 : r[insn.RA];
uint32_t ea = (uint32_t)((base + r[insn.RB]) & ~(uint64_t)0xF);
v[insn.VD] = mem_read_vec128_be(ea);
Implementation References
lvx
- xenia-canary XML:
tools/ppc-instructions.xml— search formnem="lvx" - xenia-canary emit:
src/xenia/cpu/ppc/ppc_emit_altivec.cc:139 - xenia-rs opcode:
crates/xenia-cpu/src/opcode.rs:47 - xenia-rs decoder:
crates/xenia-cpu/src/decoder.rs:775 - xenia-rs interpreter:
crates/xenia-cpu/src/interpreter.rs:1833-1840
xenia-rs interpreter body (frozen snapshot)
PpcOpcode::lvx => {
let ea = if instr.ra() == 0 { 0u64 } else { ctx.gpr[instr.ra()] };
let ea = (ea.wrapping_add(ctx.gpr[instr.rb()]) & !0xF) as u32; // aligned
let mut bytes = [0u8; 16];
for i in 0..16 { bytes[i] = mem.read_u8(ea + i as u32); }
ctx.vr[instr.rd()] = xenia_types::Vec128::from_bytes(bytes);
ctx.pc += 4;
}
lvx128
- xenia-canary XML:
tools/ppc-instructions.xml— search formnem="lvx128" - xenia-canary emit:
src/xenia/cpu/ppc/ppc_emit_altivec.cc:142 - xenia-rs opcode:
crates/xenia-cpu/src/opcode.rs:47 - xenia-rs decoder:
crates/xenia-cpu/src/decoder.rs:415 - xenia-rs interpreter:
crates/xenia-cpu/src/interpreter.rs:1841-1848
xenia-rs interpreter body (frozen snapshot)
PpcOpcode::lvx128 => {
let ea = if instr.ra() == 0 { 0u64 } else { ctx.gpr[instr.ra()] };
let ea = (ea.wrapping_add(ctx.gpr[instr.rb()]) & !0xF) as u32;
let mut bytes = [0u8; 16];
for i in 0..16 { bytes[i] = mem.read_u8(ea + i as u32); }
ctx.vr[instr.vd128()] = xenia_types::Vec128::from_bytes(bytes);
ctx.pc += 4;
}
Special Cases & Edge Conditions
- Alignment is forced, not checked. The low four bits of the effective address are cleared before the load — passing an unaligned
EAsilently reads fromEA & ~0xFrather than trapping. This differs from scalar loads (no alignment enforcement) and fromlvewxetc. (which architecturally use the exactEAfor lane placement). - Big-endian lane layout. The byte at the aligned base goes into vector lane 0 (most-significant byte); the byte at base+15 lands in lane 15. On little-endian hosts the 16-byte block is byte-swapped at the memory boundary so the PowerPC-visible layout is preserved.
RA0semantics. WhenRA = 0, the base is the literal zero. Combined with the alignment mask this letslvx VD, 0, RBload fromRB & ~0xF.- No update form. Unlike scalar loads, VMX loads have no
uvariant that post-writes the base. Uselvxlfor the cache-hint variant ("last" — the line is not expected to be reused soon). - VMX128 sibling (
lvx128). Identical semantics; the only difference is the operand encoding. VMX128 uses a 7-bit register index split across three non-contiguous bit fields (VD128l ‖ VD128h), addressingv0..v127. - Atomic 16 bytes. The read is a single conceptual load; observers see either all 16 old bytes or all 16 new bytes (to the extent the surrounding cache coherency model allows).
- Cache-line behaviour. A 16-byte aligned load fits within one Xenon 128-byte cache line; cold-line cost is one fill.
Related Instructions
stvx,stvx128— the store counterparts.lvxl,lvxl128— cache-hint "last-use" load variants.lvebx,lvehx,lvewx— single-element loads at the exact (sub-aligned) address.lvlx,lvrx— load-left / load-right for unaligned vector I/O (combine to read across alignment).
IBM Reference
- AIX 7.3 —
lvx(Load Vector Indexed) PowerISA v2.07B Book I"Vector Facility" for full vector-load semantics;lvx128is documented in the Xbox 360 XDK.