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

[Nicolás Alvarez via cfe-dev]

El jue., 24 de sep. de 2020 a la(s) 20:31, Min-Yih Hsu via cfe-dev
(cfe-dev at lists.llvm.org) escribió:
>
> Hi All,
>
> We would like to contribute our supports for Motorola 68000 series CPU (also known as M68k or M680x0) into LLVM. And we want to hear feedbacks from you
>
> 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/) 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.
>
> 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.
>
> 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
> Target-independent codegen changes. https://github.com/M680x0/M680x0-mono-repo/commit/70a6baed6afaf5fc0f5137804d130b891d54a255
> Infrastructure for the M680x0 backend.
> https://github.com/M680x0/M680x0-mono-repo/commit/f75435c9b34e7a6f2e4091b8d024b5cc391ee755
> M680x0 target information and spec.
> https://github.com/M680x0/M680x0-mono-repo/commit/9535d3dd55acb892b45f83f85906b8a6a5545f6f
> M680x0 target lowering.
> https://github.com/M680x0/M680x0-mono-repo/commit/253af82aa396ac5ea928fa2c9a6e31da70448313
> M680x0 supports for MC
> https://github.com/M680x0/M680x0-mono-repo/commit/d42bc0e355e4911c6aab6468ae12dc9e21072285
> Basic M680x0 support in Clang
> https://github.com/M680x0/M680x0-mono-repo/commit/636893780575912973130972cb5fc73153e9cbee
> M680x0 driver support in Clang
> 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.

It seems the split into multiple commits isn't correct. For example,
the "patch 3" commit doesn't compile, because it uses TargetInfo,
which is added in patch 4.

Does m68k have multiple assembly syntaxes? Which one does this backend
support? I tried compiling newlib and it fails on the assembly code
with syntax like "moveal %sp@(4),%a0".

--
Nicolás