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

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/ <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
<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.

Please feel free to leave any feedback!

Thank you for your time,
Min

[1] https://www.debian.org/ports/m68k/
<https://www.debian.org/ports/m68k/>
[2] http://wiki.netbsd.org/ports/mac68k/
<http://wiki.netbsd.org/ports/mac68k/>
[3] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html
<https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200924/dcf61154/attachment.html>

Thank you to everyone who worked on this! It looks like it's coming along
well.

What are your plans for handling the variety of ABIs used on 68000 systems? ELF
for Linux/NetBSD/SVR4 is certainly a reasonable starting point, but there was
quite a bit of variety in that area.

  -- Chris

Hi Chris,
> On Sep 24, 2020, at 9:41 PM, Chris Hanson <cmh at mac.com> wrote:
> 
> Thank you to everyone who worked on this! It looks like it's coming
along well.
Thank you :-)
> 
> What are your plans for handling the variety of ABIs used on 68000 systems?
ELF for Linux/NetBSD/SVR4 is certainly a reasonable starting point, but there
was quite a bit of variety in that area.
Currently we only support ELF for Linux. Our short-term goal is to fully support
Debian for M68K, followed by NetBSD support. So it’s likely that we will not
consider other ABIs any time soon.

Thank you
Min
> 
>  -- Chris
>

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

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

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/llvm-dev/attachments/20200927/893dcb65/attachment.html>

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>

On Mon, 28 Sep 2020 at 06:44, Min-Yih Hsu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
>
This is problematic for regression testing and bisecting to find a broken
commit. The guideline is to split the patch into multiple commits, but that
each commit builds on their own.

They don't need to have tests in between and be fully functional, but they
need to compile and not to break anything.

Usually (and very generally) people break new targets into a few steps:
 1. Adds the new directory, base table-gen files, hooks on CMake, etc.
 2. Adds target description in table-gen (registers, etc) and operations.
[this could be split in two if large]
 3. Adds codegen hooks from MIR and gets some initial "hello world"
compiled, add tests for the features added

Steps 1 and 2 should not break anything else. Step 3's tests should all
pass and not break other tests. There could be more commits than 1 per
step, but not breaking build/tests nor depending on future patches.

You should also have a buildbot with the target enabled (there's a CMake
flag for that) to show that it's green most of the time.

Optional but nice, you could have some kind of testing on "hardware"
(which
could be an emulator). Does QEMU have user emulation for 68k?

You don't need to add all hardware features nor all operations in the first
patch-set, but it's nice if the first wave can compile a hello world
program.

That's where the plan comes in. We usually ask the new community to provide
a roadmap of what features will come in which order, so that we can help
with the plan and be prepared to review the code. It also gives us more
confidence that the community is serious about adding a production target,
not just a toy target.

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