Skip to content

PowerPC: add mcrxr instruction support - #3065

Merged
Rot127 merged 1 commit into
capstone-engine:nextfrom
StilesCrisis:ppc-mcrxr
Sep 3, 2026
Merged

PowerPC: add mcrxr instruction support#3065
Rot127 merged 1 commit into
capstone-engine:nextfrom
StilesCrisis:ppc-mcrxr

Conversation

@StilesCrisis

@StilesCrisis StilesCrisis commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Your checklist for this pull request

  • I've documented or updated the documentation of every API function and struct this PR changes.
  • I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

  • Adds decode for PPC mcrxr. This opcode was eventually dropped from the Power standard, but was emitted by CW 1.2.5n.
  • See PowerPC: mcrxr (Move to CR from XER) not decoded #3066 for matching .td updates.
  • Encoding: X-form, opcode 31, XO 512. Same layout as mcrxrx (XO 576), single BF/crf operand. XO 512 is otherwise unused — no Requires<>/feature gate needed.
  • The .td def update exists in the llvm-capstone repo here: PowerPC: add mcrxr instruction definition llvm-capstone#94.
  • To keep the regen diff isolated to mcrxr, llvm-capstone's auto-sync branch was pinned to commit f6a22fb89 (2024-12-06).
  • No hand-written files (PPCDisassembler.c, PPCInstPrinter.c, PPCMapping.c) needed changes.

Test plan

  • Added cr0/cr1 entries to tests/details/ppc.yaml.
  • suite/cstest against tests/details/ppc.yaml: passed
  • suite/cstest against tests/MC/PowerPC: passed
  • Manual cstool -d check: 7c800400mcrxr cr1.

Closing issues

closes #3066

mcrxr (Move to Condition Register from XER) was part of the original
POWER/PowerPC architecture, but was dropped from Book I as of PowerPC
ISA 2.03 - superseded by the non-destructive mcrxrx on ISA 3.0+
implementations, which Capstone already decodes. It moves the top 4
XER bits (SO, OV, CA and a reserved bit) into a chosen CR field and
clears them in XER. It's still emitted by/found in legacy PowerPC and
POWER binaries, but neither v5 nor v6 currently decode it.

Encoding is X-form, opcode 31, XO 512 (same XForm_17-derived layout
LLVM already uses for mcrxrx's XO 576, just one operand: BF). That
slot is unused by any other PPC instruction, so this is added
unconditionally, without a subtarget predicate.

Since v6's PPC module is generated from capstone-engine/llvm-capstone
via Auto-Sync (see docs/ARCHITECTURE.md, suite/auto-sync/intro.md),
the actual instruction definition (a `def MCRXR : X_BF3<31, 512, ...>`
next to the existing mcrxrx, plus a P9/P10 scheduling-resource entry
each, mirroring mcrxrx) lives in that fork's PPCInstrInfo.td /
P9InstrResources.td / P10InstrResources.td, not in this repository.
This commit is the regenerated output of running `ASUpdater -a PPC`
against that change.

To keep the regen isolated to mcrxr, llvm-capstone's auto-sync branch
was pinned to commit f6a22fb89 ("Tread crbitm as register",
2024-12-06) rather than its current tip: regenerating PPC's tables
from current HEAD at the outset pulled in ~14 months of unrelated
upstream drift (register/instruction renumbering, alias/format
reclassification) alongside mcrxr, some of which broke existing
tests. f6a22fb89 was confirmed - by regenerating without the mcrxr
change and diffing byte-for-byte against every currently checked-in
PPC*.inc file - to be the exact commit the current tables were last
generated from, so this diff is now purely the mcrxr addition (plus
the expected cascading enum renumbering that coincidentally comes
from inserting any single instruction into a generated, sequentially
numbered table - see e.g. b25aa84/93a104c0/eed87476 for prior
instances of this same class of change).

include/capstone/ppc.h's generated enum region was hand-patched
(single `PPC_INS_MCRXR,` line) rather than via ASUpdater's automated
PatchArchHeader step: that step's underlying tblgen-generated
PPCGenCS*Enum.inc intermediates were reproducibly corrupted (stray
embedded NUL bytes splitting identifiers, e.g. PPC_INS_ALIAS_MR_ ->
PPC_INS_ALIAS_<NUL>R_) when built with this MSVC/Windows toolchain -
apparently pre-existing and unrelated to mcrxr, since it reproduced
identically across reruns and touched aliases mcrxr has none of.
Worth a separate look on Windows; sidestepped here since the needed
header change is a single, easily hand-verified line.

No hand-written files (PPCDisassembler.c, PPCInstPrinter.c,
PPCMapping.c) needed changes - mcrxr reuses the crrc-typed BF operand
mcrxrx already exercises.

Added an entry to tests/details/ppc.yaml (cr0 and cr1 forms) verified
against real `cs_detail` output. Confirmed no regressions: the full
suite/auto-sync/vendor cstest run against tests/details/ppc.yaml
(18/18) and tests/MC/PowerPC (5090/5090, 920 skipped) both pass,
before and after this change.

A companion PR to capstone-engine/llvm-capstone carrying the actual
.td definitions this was regenerated from should follow, so the next
official Auto-Sync run doesn't drop mcrxr again.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012jWces2QBvBWg9m3NfxH4v
@Rot127

Rot127 commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Thanks, will check it tomorrow.
On the first looks seems all good.

But please follow the PR template. And be aware that we will very soon require people to hand-write their PR descriptions: #3064

@StilesCrisis

Copy link
Copy Markdown
Contributor Author

Alright, thanks, updated with the template

@Rot127 Rot127 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@Rot127
Rot127 merged commit 73a17a4 into capstone-engine:next Sep 3, 2026
58 checks passed
Rot127 pushed a commit to capstone-engine/llvm-capstone that referenced this pull request Sep 3, 2026
mcrxr (Move to Condition Register from XER) was part of the original
POWER/PowerPC architecture, but was dropped from Book I as of PowerPC
ISA 2.03 - superseded by the non-destructive mcrxrx below on ISA 3.0+
implementations. It moves the top 4 XER bits (SO, OV, CA and a
reserved bit) into a chosen CR field and clears them in XER.

It's still found in legacy PowerPC/POWER binaries, but was never
implemented by LLVM's own PPC backend (which post-dates its removal
from the ISA), so it isn't decoded by Capstone either.

Encoding is X-form, opcode 31, XO 512 - the same XForm_17-derived
layout already used above for mcrxrx's XO 576, with the same single
BF (crf) operand. That XO slot is unused by any other PPC instruction,
so it's added unconditionally, without a Requires<> predicate.

Added a matching P9/P10 scheduling-resource entry (mirroring mcrxrx's)
in P9InstrResources.td / P10InstrResources.td: both processor models
have CompleteModel = 1, so mcrxr needs a scheduling class to keep
tblgen's schedule-completeness check passing.

This is the counterpart to capstone-engine/capstone#3065, which
carries the corresponding regenerated Capstone tables (regenerated
via ASUpdater -a PPC against this change) and has the verification
details (test suite results, encoding confirmation, etc).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012jWces2QBvBWg9m3NfxH4v
@StilesCrisis

Copy link
Copy Markdown
Contributor Author

Thank you for all your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PowerPC: mcrxr (Move to CR from XER) not decoded

2 participants