[cfe-dev] [llvm-dev] [RFC] Backend for Motorola 6800 series CPU (M68k)

[John Paul Adrian Glaubitz via cfe-dev]

Hi Renato!

On 9/28/20 11:38 AM, Renato Golin wrote:
> This is problematic for regression testing and bisecting to find a broken
> commit. The guideline is to split the patch into multiple commits, but that
> each commit builds on their own.
> 
> They don't need to have tests in between and be fully functional, but they
> need to compile and not to break anything.

I fully agree.

> Usually (and very generally) people break new targets into a few steps:
>  1. Adds the new directory, base table-gen files, hooks on CMake, etc.
>  2. Adds target description in table-gen (registers, etc) and operations.
> [this could be split in two if large]
>  3. Adds codegen hooks from MIR and gets some initial "hello world"
> compiled, add tests for the features added
> 
> Steps 1 and 2 should not break anything else. Step 3's tests should all
> pass and not break other tests. There could be more commits than 1 per
> step, but not breaking build/tests nor depending on future patches.

Thanks for the guide. I guess that should be easy to follow, and I agree,
there shouldn't be single commits that break the build.

> You should also have a buildbot with the target enabled (there's a CMake
> flag for that) to show that it's green most of the time.
> 
> Optional but nice, you could have some kind of testing on "hardware" (which
> could be an emulator). Does QEMU have user emulation for 68k?

Yes, there is qemu-user support and we're heavily relying on it within Debian
for building packages. It has some very minor issues with atomics (which aren't
present in qemu-system) and FPU support could be better, but overall it's absolutely
battle-tested.

> You don't need to add all hardware features nor all operations in the first
> patch-set, but it's nice if the first wave can compile a hello world
> program.

That already works fine, see:

> https://lists.debian.org/debian-68k/2020/06/msg00030.html

> That's where the plan comes in. We usually ask the new community to provide
> a roadmap of what features will come in which order, so that we can help
> with the plan and be prepared to review the code. It also gives us more
> confidence that the community is serious about adding a production target,
> not just a toy target.

We're definitely serious about this as otherwise we wouldn't have tried so
hard for the past years to get the development move forward and get the
backend accepted upstream.

Thanks so much for your advise, much appreciated!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913