M68k Auto-Sync update?

[Rot127]

Feature

• New architecture module
• Support for processor extension
• Add more instruction details (elaborated below)
• Binding support for: language
• Other (elaborated below)

Describe the feature you'd like

To cite @b1llow from rizinorg/rizin#5928 (comment)

Currently, Capstone's m68k is manual (supports up to M68040), while LLVM already has up to M68060.

Option A: Patch the legacy manual engine

* Implement the missing variants directly in Capstone's C code.

* Pros/Cons: Fast to deliver, but adds tech debt. We remain isolated from LLVM's M68060 support and upstream fixes.

Option B: Migrate m68k to auto-sync

* Add the new variants to LLVM's MC layer (TableGen) and pull them into Capstone via auto-sync.

* Pros/Cons: Future-proof, gets us M68060 for free, and aligns with v5+. However, it's a heavy upfront lift (handling regressions and mapping Capstone's detail struct). (Note: We only need to touch the MC layer in LLVM, no CodeGen work required).

Should we invest the time to migrate m68k to auto-sync now, or just patch the manual engine to meet the current timeline?

Answers:

@notxvilka

@b1llow patching Capstone would make sense if the architecture had an update. But since the architecture is long dead, it doesn't make sense to invest time into something that will be used only once to generate the code. Thus I suggest going with the option A. @Rot127 @wargio @thestr4ng3r @kazarmy what do you think?

@wargio

i would follow option 2

Additional context

#1917

[Rot127]

I would follow with @notxvilka here. The arc won't get updated and Auto-Sync is most important for regular updates. Since we won't run these it is likely cheaper to just add the additional instructions manually.