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

[Min-Yih Hsu via cfe-dev]

Hi All,

I just flushed out the Phabricator reviews. Here are all the patches:
1. [TableGen][M68K] (Patch 1/8) Utilities for complex instruction
addressing modes: CodeBeads and logical operand helper functions (
https://reviews.llvm.org/D88385)
2. [MIR][M68K] (Patch 2/8): Changes on Target-independent MIR part (
https://reviews.llvm.org/D88386)
3. [M68K] (Patch 3/8) Basic infrastructures and changes on object file
encoding (https://reviews.llvm.org/D88389)
4. [M68K] (Patch 4/8) Target information (https://reviews.llvm.org/D88390)
5. [M68K] (Patch 5/8) Target lowering (https://reviews.llvm.org/D88391)
6. [M68K] (Patch 6/8) MC supports and assembly (
https://reviews.llvm.org/D88392)
7. [cfe][M68K] (Patch 7/8) Basic Clang support (
https://reviews.llvm.org/D88393)
8. [Driver][M68K] (Patch 8/8) Add driver support for M68K (
https://reviews.llvm.org/D88394)

As Nicloas mentioned, you need to compile all 8 patches as a whole. Which I
think is not ideal from the point of reviewers. So I'm wondering what is
the suggestion on splitting a new target backend?

Thank you!
Min

On Thu, Sep 24, 2020 at 4:31 PM Min-Yih Hsu <minyihh at uci.edu> wrote:

> 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:
>
>    1. TableGen related changes.
>    https://github.com/M680x0/M680x0-mono-repo/commit/5b7d0ef709355f86039a799374867ba59385a79e
>
>    2. Target-independent codegen changes.
>    https://github.com/M680x0/M680x0-mono-repo/commit/70a6baed6afaf5fc0f5137804d130b891d54a255
>
>    3. Infrastructure for the M680x0 backend.
>
>    https://github.com/M680x0/M680x0-mono-repo/commit/f75435c9b34e7a6f2e4091b8d024b5cc391ee755
>
>    4. M680x0 target information and spec.
>
>    https://github.com/M680x0/M680x0-mono-repo/commit/9535d3dd55acb892b45f83f85906b8a6a5545f6f
>
>    5. M680x0 target lowering.
>
>    https://github.com/M680x0/M680x0-mono-repo/commit/253af82aa396ac5ea928fa2c9a6e31da70448313
>
>    6. M680x0 supports for MC
>
>    https://github.com/M680x0/M680x0-mono-repo/commit/d42bc0e355e4911c6aab6468ae12dc9e21072285
>
>    7. Basic M680x0 support in Clang
>
>    https://github.com/M680x0/M680x0-mono-repo/commit/636893780575912973130972cb5fc73153e9cbee
>
>    8. 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.
>
> Please feel free to leave any feedback!
>
> Thank you for your time,
> Min
>
> [1] https://www.debian.org/ports/m68k/
> [2] http://wiki.netbsd.org/ports/mac68k/
> [3] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html
>


-- 
Min-Yih Hsu
Ph.D Student in ICS Department, University of California, Irvine (UCI).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200927/893dcb65/attachment-0001.html>