[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:25 AM, Renato Golin wrote:
> One of the hardest things to do is to build a community of maintainers
> around. I used to love those architectures, and I still ran emulators on
> them, but I never contributed back with code (mainly because it's not my
> area of expertise).
> 
> But the motorola 68k still is an iconic chip and still has a large breadth
> of maintainers in other projects. I think it's reasonably safe to assume
> we'll attract some of them into LLVM for the foreseeable future. That would
> be a big win for us.

Yes, I fully agree. To underline how big the community is, let me just share
a short anecdote. Previously, the GCC m68k backend had to be converted from
the CC0 register representation to MODE_CC. We collected donations within the
Amiga and Atari communities and within just a few weeks, we collected over
$6000 which led to an experienced GCC engineer with m68k background to finish
that very extensive work in just a few weeks.

So, I think in case there was a problem with the backend in LLVM, the community
would have enough momentum to work towards solving this issue.

> For now, codegen quality and ABI conformance probably won't be on par with
> the target's requirements (discussion on pascal vs C for example), but
> that's a solvable problem. If the code follows the LLVM policies and the
> maintainers have a clear list of points to address, introducing it as
> experimental would be a reasonably trivial thing to do.

I'm very happy to hear that :-).

> In theory, a target can remain in "experimental" mode for a while. But the
> more it does, the harder it gets to keep it working. Basically, the cost of
> doing that falls almost entirely on the local target's community while
> experimental.

I agree. But we will enable the target in Debian the moment it becomes usable
and we will expose it to as much testing as possible to unconver bugs or remaining
features and report them upstream.

We have made very good experiences in Debian Ports with using experimental software
for production in order to iron out bugs. This way we smashed dozens of bugs in
QEMU, for example which has a very good m68k emulation these days.

> It's not until the target is built by default (leaves experimental status)
> that the other buildbots start building and testing them, and developers
> start building it locally and fixing issues before submitting the review.

I understand, thanks for the clarification. That's why I'll make sure the
backend gets used in Debian as early as possible.

> But the quality has to be "production" by then, so the 68k community in
> LLVM should really have a plan to remove the experimental tag soon.
> Maintenance after that reduces to continuous development (new features) and
> bug fixing and is much more amenable.

Gotcha.

> Has anyone compiled a list of features that will be added and what's the
> timeframe for them? What's to be done during the experimental phase and
> afterwards?

We have a rough list of remaining issues in [1] and [2]. Min also gave a talk
in [3] where he drafted out the TODO and plans for the backend [3]. The talk
is also available on Youtube [4].

Adrian

> [1] https://github.com/M680x0/M680x0-llvm/issues
> [2] https://github.com/M680x0/M680x0-mono-repo/issues
> [3] http://m68k.info/#org77ef882
> [4] https://www.youtube.com/watch?v=-6zXXPRl-QI

-- 
 .''`.  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