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