Looking for backers to support the funding of modernizing gcc on m68k

[adrian82]

Hello!

As some of you may know, the latest version of gcc still supports m68k as a target architecture which is great as it means that even the latest C++ standards are supported on the original architecture of the Amiga.

However,  since the m68k backend has not received one important modernization change [1, 2], the backend is in danger to be removed from gcc.

Since we would like to continue to keep m68k as an unofficial architecture in Debian, I have created a bounty on BountySource.com so that someone with experience with gcc can work on the task and therefore help preserve m68k support for future versions of gcc.

If anyone here is interested in supporting our cause, please consider making a small donation:

> https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

Thanks,
Adrian

> [1] https://gcc.gnu.org/wiki/CC0Transition
> [2] https://gcc.gnu.org/backends.html

[kamelito]

Bebbo is already improving GCC but I guess a bounty is welcome.
https://github.com/bebbo

[TribbleSmasher]

Is there any guarantee the responsible maintainer/coder will continue to support the changes after funding is used up?
Whatif the port for m68k is removed completely a year later? We are talking about ancient platforms here, after all.

[adrian82]

Bebbo is already improving GCC but I guess a bounty is welcome.
https://github.com/bebbo

Yes, I'm aware of his efforts and I've also been in contact with him.

However, he was mostly focused on bug fixes and not working on the cc0 transition which is mandatory if we want to keep m68k support in the future.

Adrian

[adrian82]

Is there any guarantee the responsible maintainer/coder will continue to support the changes after funding is used up?

The m68k backend currently has an active maintainer [1] so he will take care of the code after it has been converted to MODE_CC. Since the conversion is a bit of a longer task (according to one of the gcc maintainers, it's about one month of work), he doesn't seem to be interested in this work at the moment.

Whatif the port for m68k is removed completely a year later? We are talking about ancient platforms here, after all.

It's very unlikely that it's being removed in the near future after the conversion has happened. I have talked to gcc upstream about the task and their requirement for keeping the port is simply the MODE_CC conversion.

Adrian

> [1] https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS#L80

[SamuraiCrow]

Development seems stalled on https://github.com/M680x0/M680x0-llvm too.  It's not abandoned though.

[kolla]

@SamualCrow
I know of a certain team that have "reviving the 68k" on their agenda - here is probably _the_ opportunity for them.

[adrian82]

Development seems stalled on https://github.com/M680x0/M680x0-llvm too.  It's not abandoned though.

Not sure how llvm-m68k is related, but unfortunately, the project is currently in a limbo as the original developer currently doesn't have any plans to continue working on it.

He has actually invited me to the "M680x0" project and I have made some small contributions, but overall, we're currently stalled.

I think it would be a good candidate for another bounty on BountySource .

But for the time being, it would be more important if the community could join forces to help modernize the m68k backend in gcc which is the most pressing task for free software on m68k at the moment.

Adrian

[SamuraiCrow]

Re:GCC vs. LLVM

Since LLVM is used for JITs and is modular enough that it might be able to break down into small enough units that it could run on a RAM expanded Amiga outright.  (Assuming it has a custom pass manager that only loads in the currently executing pass and flushes out all others.)  GCC is popular among Linux Distros, that's true, but even Mandriva uses Clang instead of GCC when possible.

@adrian82

Since you've worked with both LLVM and GCC, can you tell me if such a hand-over-hand pass manager would be possible on a recent GCC?  Also, how much more work is required to finish the LLVM backend?

Re:Bounties

Looking at the BountySource page it's got about $1300 in it for GCC already.  If we only get one shot at it though, I'd prefer Clang over GCC for the reasons I described above.

[adrian82]

Re:GCC vs. LLVM

Since LLVM is used for JITs and is modular enough that it might be able to break down into small enough units that it could run on a RAM expanded Amiga outright.  (Assuming it has a custom pass manager that only loads in the currently executing pass and flushes out all others.)  GCC is popular among Linux Distros, that's true, but even Mandriva uses Clang instead of GCC when possible.

Clang is not really mature enough yet to build Debian packages and especially the kernel on all architectures. So I wouldn't be too optimistic.

Modernizing the m68k backend in gcc is currently the easier task.

Since you've worked with both LLVM and GCC, can you tell me if such a hand-over-hand pass manager would be possible on a recent GCC?

JITs are currently not our focus. gcc is gaining JIT support, but for the time being, the most important goal is to be able to use a modern C/C++ compiler on m68k.

Also, how much more work is required to finish the LLVM backend?

The TODO list can be found here: https://github.com/M680x0/M680x0-llvm/issues

Looking at the BountySource page it's got about $1300 in it for GCC already.  If we only get one shot at it though, I'd prefer Clang over GCC for the reasons I described above.

I disagree. LLVM/Clang is still much further ahead, in particular it will be very hard to upstream m68k support. For gcc, on the other hand, the only task is to convert the backend to MODE_CC in order to keep it in future versions of gcc.

Adrian

[wawrzon]

perhaps it would be best to start with aros set of patches to gcc and llvm/clang. these are among others meant to produce 68k code. latest supported 68k compiler backend is gcc 9.1 afair. the aros patches are meant as minimal. do not introduce optimisations absent upstream. and produce elf binaries. hunk binaries are being generated from these via elf2hunk utility.

[slaapliedje]

There are people in the Atari community also working on gcc improvements on m68k.  https://github.com/freemint/m68k-atari-mint-gcc

[adrian82]

perhaps it would be best to start with aros set of patches to gcc and llvm/clang. these are among others meant to produce 68k code.

AROS has an out of tree LLVM backend for m68k? Where? And what patches do they have for gcc?

latest supported 68k compiler backend is gcc 9.1 afair.

The thing is. If we don't get this task finished that I started the BountySource campaign for, all projects working on m68k will be stuck with gcc-10 forever as all cc0 backends are planned to be removed for gcc-11. So, this is actually rather urgent.

the aros patches are meant as minimal. do not introduce optimisations absent upstream. and produce elf binaries. hunk binaries are being generated from these via elf2hunk utility.

This isn't about optimizations or generating HUNK binaries. This is about making sure m68k support is not killed off with gcc-11.

There are people in the Atari community also working on gcc improvements on m68k.  https://github.com/freemint/m68k-atari-mint-gcc

This is an outdated gcc tree from 2018 according to the ChangeLog file. Won't help us.

Adrian

[kolla]

@adrian82

I see VAX is also among the "endangered species" - is there a similar effort to keep it alive?
What counts as "a Free simulator"? I see m68k has "?" on that column.

( Also, perhaps a Linux/68k port of Toni Wilen's 68k CPU core tester/validator is possible?
http://eab.abime.net/showthread.php?t=98747 )

[wawrzon]

AROS has an out of tree LLVM backend for m68k? Where? And what patches do they have for gcc?

actually aros patches are not platform specific. afair i have once tried to compile the latest clang/llvm toolchain there is (llvm7) with aros patch for m68k but i havent went far, let alone it worked. but gcc 9.1 works.
the crosstools patches are here:
https://github.com/aros-development-team/AROS/tree/master/tools/crosstools

The thing is. If we don't get this task finished that I started the BountySource campaign for, all projects working on m68k will be stuck with gcc-10 forever as all cc0 backends are planned to be removed for gcc-11. So, this is actually rather urgent.

im not questioning your initiative, even if i cannot contribute as present.

This isn't about optimizations or generating HUNK binaries. This is about making sure m68k support is not killed off with gcc-11.

the patches i mentioned are used to adopt the compiler to the system itself, since the architecture is still supported anyway, it doesnt probably help anything to bother with amigaos or aros patches, one simply needs to work on the upstream 68k backend. sorry for a stupid proposal.