Bountysource campaign for the M68000 backend

Hello!

Almost two years ago, Artyom Goncharov submitted an initial effort for a
backend for the Motorola 68000 architecture [1] which was eventually
not merged, unfortunately. I elaborated why I supported the idea of
such a backend [2].

Recently, we started a fundraising campaign on the platform Bountysource.com
to port the M68K backend in GCC to the new MODE_CC register representation
which was very successful collecting over $6000 in donations financing an
experienced GCC developer to complete the task in a short period [3].

Due to the success of the GCC campaign, people in the Amiga community are
wondering whether such a campaign would work for LLVM as well to complete
the M68000 backend started by Artyom [4] and maybe also get it merged
into LLVM upstream. The list of remaining tasks on the backend are tracked
in the issue tracker for the M68000 backend on Github.

I think such a backend has good chances of attracting maintainers and
developers as there is still a considerably large community around the
M68000 architecture. I recently learned that there are even people at
Google working on Amiga code in their free time.

What does the LLVM community think? Would it be okay in principle to start
such a fundraising campaign and would there be someone on the list interesting
on working on this project provided that we are able to collect enough
funds?

Thanks,
Adrian

Hi John,

I don't speak for the entire community, but I believe that there are likely to be two potential issues:

1. How different is M68K to modern architectures (reluctantly including x86)? Will this add any maintenance burden to the target-agnostic code generator? If so, how much and will there be contributors willing to help carry that to retain M68K support?
2. Who is going to commit to maintaining the port? For example, the original version used SelectionDAG, which will eventually be phased out in favour of GlobalISel. This involves some quite major changes to back ends, which is why back ends are only committed if they have a code owner who is willing to provide long-term maintenance.

I don't think that a one-off donation mechanism is a great way of getting someone to do this long-term, but if you have someone in mind who is willing to do it but needs some seed capital to get it into a good state initially, that may work.

LLVM, in general, is pretty happy to remove things that are slowing down development and have no active maintainers, so if the M68K maintainer went away there is a danger that the back end would be dropped. How would backers of the bounty program react if the code were added, the bounty paid, and then the code removed a year later? I think I'd be pretty annoyed if I'd paid into something like that on the assumption that I'd have an LLVM back end, but end up with an LLVM 11 and LLVM 12 back end that is then not in LLVM 13.

If you can come up with a plan for long-term maintenance (ideally a small group of people willing to say 'we will do code review of the initial implementation and then maintain it'), then I think this would be a great contribution.

David

Yeah, I’d agree pretty much with what David Chisnall said - that this might not be the best way to get something into LLVM. A short term contract without other demonstrated community involvement (even with the position that it’ll come after the short term contract) is sort of a clear example of what wouldn’t be good to have committed to the LLVM project itself. Though the experimental targets system would at least provide an in-tree way to get the target in and demonstrate continued community involvement (but with the risk, as David pointed out, that if that ongoing involvement doesn’t eventuate, the target would be deleted and some people who paid for the target work might be disheartened).

Maybe a github fork would be a better place to start such work - setting expectations a bit lower, less resentment because it wouldn’t be deleted due to lack of maintenance & if it is well maintained, that might help provide the demonstrated ongoing interest that would be useful in adding it as an experimental target and then hopefully non-experimental.

  • Dave

Hi David!

Thanks a lot for your feedback!

I don't speak for the entire community, but I believe that there are likely to be two potential issues:

1. How different is M68K to modern architectures (reluctantly including x86)? Will this add any
   maintenance burden to the target-agnostic code generator?

I don't think m68k is particularly odd. It does not have a stack growing into the opposite
direction or even two stacks like ia64 and has equivalent instructions for most instructions
that x86 has. There is even full support for compare-and-swap despite the architecture
being so old unlike older SPARC or older ARM.

The only oddity of m68k on Linux is that the default alignment is 2 bytes instead of 4 bytes,
despite the architecture being 32 bits.

If so, how much and will there be contributors willing to help carry that to retain M68K support?

We don't have any dedicated maintainer for the LLVM m68k backend yet, but my hope is to find
one through this mailing list or another community. As I have mentioned in my first mail,
there are a lot of developers in the community and at companies due to the popularity of
the Amiga.

2. Who is going to commit to maintaining the port? For example, the original version used
   SelectionDAG, which will eventually be phased out in favour of GlobalISel. This involves
   some quite major changes to back ends, which is why back ends are only committed if they
   have a code owner who is willing to provide long-term maintenance.

Since we're still looking for a dedicated maintainer, I cannot answer this question yet,
unfortunately.

I don't think that a one-off donation mechanism is a great way of getting someone to do this
long-term, but if you have someone in mind who is willing to do it but needs some seed capital
to get it into a good state initially, that may work.

I fully agree and I understand that LLVM is a very volatile project.

LLVM, in general, is pretty happy to remove things that are slowing down development and
have no active maintainers, so if the M68K maintainer went away there is a danger that
the back end would be dropped.

Yes, I know this and I think in one sense this is very unfortunate. LLVM is really a key
project these days and having backend support for a particular architecture in LLVM
means that one gets support for a variety of new languages and technologies with very
little effort since LLVM is so incredibly versatile.

For example, adding support for a new architecture in Rust requires probably less than
500 lines of code once LLVM has support for this architecture. And with more and more
projects including Rust in their code bases, being a supported backend architecture
in LLVM becomes more and more attractive.

How would backers of the bounty program react if the code were added, the bounty paid,
and then the code removed a year later? I think I'd be pretty annoyed if I'd paid into
something like that on the assumption that I'd have an LLVM back end, but end up with
an LLVM 11 and LLVM 12 back end that is then not in LLVM 13.

Yes, I absolutely agree that this is a problem and I don't know a particular solution
to this yet. I think it's really a pity that the barrier for getting into LLVM is so
high.

If you can come up with a plan for long-term maintenance (ideally a small group of people
willing to say 'we will do code review of the initial implementation and then maintain it'),
then I think this would be a great contribution.

That might be a good idea. FWIW, QEMU has pretty good emulation support for m68k these
days. In fact, the GCC developer who recently converted the m68k backend in GCC to
MODE_CC used QEMU as well running a current version of Debian unstable.

Adrian