[M68000] Add Motorola CPU32 (683xx) support

[dzidaV8]

Currently Ghidra lacks CPU32 (Motorola/Freescale 683xx) processor support.

CPU32 instruction set is same as 68020, with exception of:

The folllowing instructions are CPU32 specific:

• LPSTOP — low-power stop
• TBLxxx — table lookup and interpolate

The following M68020 instructions are NOT implemented on the CPU32:

• BFxxx — Bit Field Instructions (BFCHG, BFCLR, BFEXTS, BFEXTU, BFFFOBFINS, BFSET, BFTST)
• CALLM, RTM — Call Module, Return Module
• CAS, CAS2 — Compare and Set (Read-Modify-Write Instructions)
• cpxxx — Coprocessor Instructions (cpBcc, cpDBcc, cpGEN, cp RESTORE,cpSAVE, cpScc, cpTRAPcc)
• PACK, UNPK — Pack, Unpack BCD Instructions

I have made some effort to try and add CPU32 instructions in my fork.

CPU32 Reference Manual

[jonofmac]

DzidaV8,
Thanks for posting this. You're not the only one who would really like the full CPU32 instruction set support in Ghidra. I'm currently decompiling a binary for the 683xx family and it barfs on a lot of the instructions since I don't have the TBLxxx instructions.

I'll take a look at your fork and see what I can do to assist. I only just discovered Ghidra and am impressed with it, but was a little sad to see it didn't have CPU32 support yet.

[LegacyNsfw]

I would also love to see CPU32 fully supported. Thank you for getting this started, dzidaV8.

[dzidaV8]

I've been tinkering with the .sinc file but I can't wrap my head around how the p-code works and I can't get rid of errors. If anybody could help with my fork, please do!

[LegacyNsfw]

I started with dzidaV8's code, removed everything in the { } for the moment, and focused on just getting the Sleigh to compile... After much cursing I made the tiniest bit of progress: Ghidra decoded a tbl instruction! But only one, after which the disassembler quit.

It's a start.

LegacyNsfw@3f71c44

I'll work on this some more tomorrow...

[LegacyNsfw]

No progress today due to this surprise: #2600
I'm building Ghidra in Eclipse now to see if I can get to the bottom of that problem in the debugger.

But the new Sleigh code is actually a bit better than I thought, It is successfully disassembling most tblxx instructions. But there is at least one addressing mode that isn't supported yet. It should not be hard to fix, but I'm still stumped.

Current state of the change: https://github.com/LegacyNsfw/ghidra/tree/nsfw/cpu32

[LegacyNsfw]

Lots of progress today, in fact I'm on the verge of sending a pull request. I've rebased my changes on top of dzidaV8's, partly for the sake of attribution and partly because dzidaV8's changes were more complete. New branch here:

https://github.com/LegacyNsfw/ghidra/tree/nsfw/cpu32-pr

The thing I'm least sure about is the pcode for the TBL instructions. Rather than dzidaV8's actual implementation of the instructions, I just went with custom pcode operations, because it makes the decompiled version look nice, e.g.

uVar4 = tableLookup(iVar5 ,DAT_0000d658);
uVar2 = tableLookup(iVar5, DAT_0000d64e);

I think that's preferable to seeing the actual implementation of the table-lookup algorithm. I'm primarily interested in readability of decompiled code, because my goal is to understand the code I'm studying, and I won't be trying to execute it, at least not soon.

However I'm not sure everyone else will feel the same way. And I probably will want to run it in an emulator at some point. If there's a way to get the best of both worlds (readable code in the decompile window, while retaining the ability to emulate), I'd love to know how to do that.

Hi @LegacyNsfw , nice work!

I'm just trying out your pr, but fail with:

Is there a update missing, or something else I'm doing wrong?

[LegacyNsfw]

Sorry, but I haven't seen that error, and I don't know what it means.

You might try copying the contents of the processors/68000/data/languages directory from my repo into the corresponding folder in your Ghidra installation. Then restart Ghidra, and it will recompile the Sleigh files automatically.