#1244 Add CPU32 processor variant with full instruction set support

[polartape]

Summary

Add Motorola CPU32 processor variant to the 68000 processor module. Closes #1244.

CPU32 is based on the 68020 instruction set with some instructions removed and table lookup/interpolation instructions added. Used in MC68330, MC68340, MC68360 and similar microcontrollers.

Credits

This work builds on PR #2617 by @LegacyNsfw which provided the original CPU32 SLEIGH implementation. See also PR #8463 by @jlaustill which updates PR #2617 for current Ghidra. This PR additionally excludes unsupported instructions, adds BGND/LPSTOP, fixes TBL addressing modes, and includes pcode emulator test classes.

Changes

• 68000.sinc: @ifdef/@ifndef CPU32 conditionals for instruction set differences
  • Added: TBL_ADDR_MODES macro, tbl_instrA 32-bit token, TBL EA subtables (all addressing modes including predecrement and displacement)
  • Added: TBLS/TBLSN/TBLU/TBLUN table lookup and interpolate (all sizes and rounding modes)
  • Added: TBL data register interpolate (all sizes and rounding modes)
  • Added: LPSTOP, BGND
  • Excluded via @ifndef CPU32: BFxxx (8 bitfield instructions), CALLM, CAS, CAS2, PACK, RTM, UNPK (per CPU32 Reference Manual Rev 1, Dec 1990, Section 1.1 and opcode map pp. 229-247)
• CPU32.slaspec: New language specification (@define CPU32, @define MC68332)
• 68000.ldefs: CPU32 variant definition (68000:BE:32:CPU32)
• certification.manifest: CPU32.slaspec entry
• Emulator test classes for CPU32
• pcode_defs.py: CPU32 pcodetest build configuration

Building pcode test binaries

Test binaries require m68k-linux-gnu-gcc with -mcpu=cpu32. The standard cross-compiled libgcc.a contains 68020 bitfield instructions (BFFFO in __divdi3/__moddi3/__udivdi3) not available on CPU32. A modified libgcc.a with CPU32-compatible C replacements for these functions is needed. Float/double tests are excluded since CPU32 has no FPU.

Test plan

• SLEIGH compiles without errors for all variants (CPU32, 68020, 68030, 68040, Coldfire)
• CPU32 pcode emulator tests pass: 16/16 O0, 16/16 O3 (1389 assertions each)
• m68000 pcode emulator tests unchanged: 17/17 O0, 17/17 O3
• All 79 CPU32 instructions verified against CPU32 Reference Manual (Rev 1, Dec 1990)
• No new SLEIGH warnings introduced

AI (Claude Code) was used to assist with verification, testing, and implementation.

[jobermayr]

Here are real differences to #8463 (moved your last #ifdef CPU32 block within 68000.sinc): https://github.com/jobermayr/ghidra-staging/blob/master/9084-1244-Add-CPU32-processor-variant-with-full-inst.patch

[polartape]

Thanks for the comparison. To clarify the actual differences from #8463: the @ifndef CPU32 exclusions (restoring what was in #2617), uncommenting the TBL predecrement/displacement modes for word and byte sizes, and the pcode emulator test infrastructure.

[jlaustill]

Heya, I just want to see this support merged so I don't have to maintain my own fork :) I did not do any of this original work and just tried to bring others work up to date with main so it was mergable. If you are more familiar with this stack I'm happy to let y'all carry the torch and support you if I can. Let's just get this support merged :)

[GhidorahRex]

I have been in the process of reviewing #8463 and I have no problem prioritizing one over the other. Having the pcodetests here helps, as well as the additional two instructions. It would be good to verify that the gcc toolchain will generate the tbl instructions.

For bgnd I think it's worth adding a pcodeop define pcodeop background_mode; Same for lpstop, too. They don't have to be implemented, but having the pcodeop hint in the decompiler can be helpful.

I'm less concerned about the instructions that are ifndef out - they're definitely not supported by the CPU32 so it's accurate, but as long as they don't collide in the opcode map it shouldn't be a problem. It can become a headache if there are a lot of processor variants with varying instruction support (PowerPC comes to mind), but for the 68k, there's only a handful, so I think it's a reasonable addition.

[polartape]

TBL disassembly verified with all addressing modes (mode 2/4/5/7), all sizes (B/W/L), all variants (TBLS/TBLU/TBLSN/TBLUN), and both table lookup and register interpolate forms — 60 instruction encodings total, verified through Ghidra disassembly. The FPU exclusion (@ifndef CPU32) was needed to resolve a line-F opcode conflict that prevented TBL modes 5 and 7 from disassembling correctly.

Added define pcodeop background_mode for BGND and define pcodeop low_power_stop for LPSTOP as suggested. GCC does not generate TBL instructions from C code so they cannot be verified through the pcodetest framework.

[polartape]

Implemented full TBL pcode semantics replacing the pcodeop placeholders. The implementation covers all variants (TBLS/TBLU/TBLSN/TBLUN), all sizes (B/W/L), both table lookup and register interpolate modes, including the signed rounding algorithm from RM p.213 and VF overflow detection for unrounded long results. Verified through Ghidra's emulator with 34 test cases covering the manual's worked example, rounding boundary conditions, signed/unsigned, all three sizes, rounded and unrounded modes, register interpolate, and VF overflow — all passing.

This is a larger change that may be harder to review. Would you prefer it as a separate follow-up PR after this one is merged, or included here?

[GhidorahRex]

Implemented full TBL pcode semantics replacing the pcodeop placeholders. The implementation covers all variants (TBLS/TBLU/TBLSN/TBLUN), all sizes (B/W/L), both table lookup and register interpolate modes, including the signed rounding algorithm from RM p.213 and VF overflow detection for unrounded long results. Verified through Ghidra's emulator with 34 test cases covering the manual's worked example, rounding boundary conditions, signed/unsigned, all three sizes, rounded and unrounded modes, register interpolate, and VF overflow — all passing.

This is a larger change that may be harder to review. Would you prefer it as a separate follow-up PR after this one is merged, or included here?

I think that should probably be a follow-up PR.