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

On Sun, 27 Sep 2020 at 20:27, John Paul Adrian Glaubitz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As many of these classic systems still have very active communities,
> especially the Amiga community,
> development efforts are still very strong. For example, despite being the
> oldest port of the Linux
> kernel, the m68k port has still multiple active kernel maintainers and is
> regularly gaining new
> features and drivers.
>
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.

I think this, and other topics in the requirements' list [1] are covered
for the 68k.

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.

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.

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.

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.

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?

cheers,
--renato

[1] http://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/860d806f/attachment.html>

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

On Mon, 28 Sep 2020 at 10:37, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> 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.
>
Great!

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.
>
That's good to hear. The Debian project has helped us do extensive tests in
other hardware and it provided us with confidence that what we build
actually works in some real world context.


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].
>
So, IIUC, the current implementation is reasonably complete. You're able to
compile C programs and run them on real hardware. The main effort now is to
upstream what you have, and continue the development.

This would make the "plan" easier. Getting the current state upstream
would
make for a nice experimental target. Getting Debian packages compiled and
tested with QEMU would demonstrate production quality.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/f311f3e6/attachment.html>