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

Sun Sep 27 12:27:43 PDT 2020

Hello!

On 9/25/20 1:31 AM, Min-Yih Hsu wrote:> Here is some background for M68k: Motorola 68000 series CPU was one of the most popular CPUs used
> by personal computers in the ‘80, including some of the earliest Apple Macintosh. Fast-forwarding
> to modern days, M68k is still popular among retrocomputing communities - a bunch of people doing
> cool stuff, mostly porting modern software and systems, on old computers. For example, Planet m68k
> (http://m68k.info/ <http://m68k.info/>) is a portal and a bulletin board for many communities that
> focus on specific M68k computer models, Amiga, Atari, Mac68k to name a few, to share their news.
> Major operating systems like Debian [1] (Adrian in the CC list can back me up on the Debian part)
> and NetBSD [2] also support M68k. Long story short, there is a big community and a huge amount
> of developers in this ecosystem.

Adding to this: Despite its age, the Motorola 68000 is still a very popular architecture due to the
fact that the CPU was used by a wide range of hardware from the 80s throughout the 2000s. It is
used in the Amiga, Atari, Classic Macintosh, Sega MegaDrive, Atari Jaguar, SHARP X68000, various
Unix workstations (Sun 2 and 3, Sony NeWS, NeXT, HP300), many arcade systems (Capcom CPS and CPS-2)
and more [1].

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. There are companies still developing new hardware around the CPU (like
Individual Computers, for example) like network cards, graphics adapters or even completely
new systems like the Vampire [2].

Since we would like to be able to keep up with modern software development on m68k, we need a modern
toolchain which necessarily includes LLVM due to the fact that it's needed for modern languages
like Rust. In particular, several projects like GNOME have started rewriting parts of their
codebases in Rust which is why any architecture that is supposed to run modern versions of
GNOME and related projects needs Rust support and therefore a working LLVM backend.

But Rust is naturally not the only reasons why having an LLVM backend is useful for the m68k
architecture, another very compelling argument is that NetBSD can use a modern C/C++ for their
m68k with a permissive license and the retro-computing and video gaming community gets a compiler
with built-in cross-compiling capabilities which is incredibly valuable for anyone developing
new software for retro-computing platforms like the Amiga, Atari or Sega MegaDrive.

> Some of you might remember that LLVM backend for M68k has been brought up in the mailing list sever
> times. The latest one was in 2018 [3]. Though those attempts never went through, we learned precious
> lessons: It’s important to show who’s behind this backend, how sustainable they are, and how we can
> make these changes easy to review.

> As I illustrated earlier, majorities of the participants in the M68k community are hobbyists and
> non-profit groups. So do the people behind this backend: Currently there are three core members
> (CC’ed): Adrian, Artyom, and me. All of us participate in this project as individual contributors.
> I know the fact that we’re not supported (financially) by any institution or organization will put
> us in a lower hand when it comes to reliability. However, the quality of the backend has improved
> quite a lot since the last discussion. We’ve also settled down the code owner / primary maintainer.
> Not to mention we’ve been working closely with the rest of the M68k community to help us improve
> the testing. On the financial side, we’re trying to open up a donation campaign (e.g. Patreon).
> Though that involves many other practical issues so we’re still discussing that. LLVM is an open
> and inclusive community accepting contributions from talented people all over the world, regardless
> of their backgrounds. I believe this virtue can still be seen in the support of hardware backends,
> where each of the targets is judged by its code quality, maintenance, and user base. Rather than
> which company supports it.

Very well said. I would like to add here that LLVM can be considered to be one of the most important
open source projects currently in existence and having ones architecture supported by LLVM means that
the language support for that architecture dramatically improves. So, with LLVM supporting m68k, the
architecture will get a significant boost allowing it to reach even wider communities, especially the
Rust community.

This means there will be new software being written for the architecture as we're attracting new
developers. For example, there might be Rust developers interested to develop new games for the
Sega MegaDrive or new software for the Amiga. While this certainly doesn't have much of a big
commercial factor, it definitely has a huge community factor due to the fact the m68k architecture
is so popular among hobbyists.

As for the maintainership: As Min explained we're going to make sure the architecture has a dedicated
maintainer once its in LLVM so it doesn't bitrot. Our idea was that multiple people are joining a
Patreon to pay Min a little sponsoring fee every month to support him with the maintenance effort
so he doesn't have to do the work for free. So while that won't be as professional as someone being
hired to work on LLVM by one of the big players, at least we will have a dedicated maintainer that
is being paid to do the maintenance work.

> Last but not the least, on the technical side, we’ve ported the code base onto ToT, and splitted all
> the changes into 8 patches, organized by their functioning. I’ll put them onto Phabricator later.
> Meanwhile, you can checkout the exact set of patches in our out-of-tree repo:

> TableGen related changes.

> https://github.com/M680x0/M680x0-mono-repo/commit/5b7d0ef709355f86039a799374867ba59385a79e
> <https://github.com/M680x0/M680x0-mono-repo/commit/5b7d0ef709355f86039a799374867ba59385a79e> 

> Target-independent codegen changes.
> https://github.com/M680x0/M680x0-mono-repo/commit/70a6baed6afaf5fc0f5137804d130b891d54a255
> <https://github.com/M680x0/M680x0-mono-repo/commit/70a6baed6afaf5fc0f5137804d130b891d54a255> 

> Infrastructure for the M680x0 backend.
> https://github.com/M680x0/M680x0-mono-repo/commit/f75435c9b34e7a6f2e4091b8d024b5cc391ee755
> <https://github.com/M680x0/M680x0-mono-repo/commit/f75435c9b34e7a6f2e4091b8d024b5cc391ee755> 

> M680x0 target information and spec.
> https://github.com/M680x0/M680x0-mono-repo/commit/9535d3dd55acb892b45f83f85906b8a6a5545f6f
> <https://github.com/M680x0/M680x0-mono-repo/commit/9535d3dd55acb892b45f83f85906b8a6a5545f6f> 

> M680x0 target lowering.
> https://github.com/M680x0/M680x0-mono-repo/commit/253af82aa396ac5ea928fa2c9a6e31da70448313
> <https://github.com/M680x0/M680x0-mono-repo/commit/253af82aa396ac5ea928fa2c9a6e31da70448313> 

> M680x0 supports for MC
> https://github.com/M680x0/M680x0-mono-repo/commit/d42bc0e355e4911c6aab6468ae12dc9e21072285
> <https://github.com/M680x0/M680x0-mono-repo/commit/d42bc0e355e4911c6aab6468ae12dc9e21072285> 

> Basic M680x0 support in Clang
> https://github.com/M680x0/M680x0-mono-repo/commit/636893780575912973130972cb5fc73153e9cbee
> <https://github.com/M680x0/M680x0-mono-repo/commit/636893780575912973130972cb5fc73153e9cbee> 

> M680x0 driver support in Clang
> https://github.com/M680x0/M680x0-mono-repo/commit/c5834ffbda019df8c94c669c658d804cb9c19af3
> <https://github.com/M680x0/M680x0-mono-repo/commit/c5834ffbda019df8c94c669c658d804cb9c19af3> 
> 
> As you can see, some of the patches also touch some target-independent parts like TableGen.
> We tried to minimize their scope, make sure they’re optional and won’t break any existing code.
> I’ll justify them in their Phabricator pages, or even open up new threads here on the mailing list.

Much appreciated, Min. I can't thank you enough for your hard work and I'm really excited to
see this going forward. I hope that we will soon be able to get the first bits for m68k merged
soon the same way the first changes for C-Sky are being merged.

I'm keeping my fingers crossed and I hope that our long-time efforts are being rewarded by LLVM upstream :).

Adrian

> [1] https://en.wikipedia.org/wiki/Motorola_68000#Applications
> [2] https://www.apollo-accelerators.com/
-- 
 .''`.  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