[llvm-dev] PowerPC LLVM support much appreciated

[Andrew Chiw via llvm-dev]

Hello Iain,

Recently I decided to set myself the entirely alien task of getting Rust
to work on PowerPC Darwin (10.4/10.5). I mostly program in Python/Go and
am a newbie to Rust. Nevertheless, I've done some research and asked
around on LLVM discord and was told to direct my questions to you.

Being new to compiler/assembler development, could you fill me in on the
scope of this task I've just set myself?

The instructions here
https://github.com/iains/darwin-toolchains-start-here seem incomplete,
and for someone who doesn't know much about compiler development like
me, I think it's missing quite a bit of context. Does it work, would I
get a LLVM which I could use to compile LLVM IR generated by rustc?

Looking at the LLVM changelog, I have the impression that LLVM's major
versions don't change that much, so later versions of LLVM shouldn't be
too hard to get working either, am I correct?

What other roadblocks do you foresee? I was under the impression that I
only need to get LLVM to emit PowerPC MachO, but since then I have also
heard that I need to get Rust to work with 10.4/10.5's libc... which
means both language and compiling backend need to have access to the
10.4/10.5 libraries... which means I shouldn't try to setup a cross
compiler with my current state of knowledge. More clarification/context
much appreciated.

Kind regards,

Andrew Chiw

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Qiu Chaofan via llvm-dev]

Hi,

Darwin support in PowerPC backend was deprecated in LLVM 8.0.0 (https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html) and some was removed in later releases. So you need an earlier LLVM version to generate code on Darwin PowerPC, which may not be fully compatible with latest rustc.

Regards,

[John Paul Adrian Glaubitz via llvm-dev]

Hello!

On 10/22/21 09:50, Qiu Chaofan via llvm-dev wrote:
> Darwin support in PowerPC backend was deprecated in LLVM 8.0.0 and some was

> removed in later releases. So you need an earlier LLVM version to generate
> code on Darwin PowerPC, which may not be fully compatible with latest rustc.

I don't think it would take much to bring back support for Darwin/PowerPC as
long as the generic support for Darwin and PowerPC is still present in LLVM
and Rust.

I mean, we have support for M68k ;-).

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[Nemanja Ivanovic via llvm-dev]

Bringing back support for Darwin/PowerPC is of course possible, but such undertakings are not free. Aside from the effort to bring it back, there is the effort of maintaining that support as the PowerPC back end continues to be developed for supported platforms (Linux, AIX, FreeBSD). So in order to consider bringing it back, we would really need to understand the use case - now and in the future.

[John Paul Adrian Glaubitz via llvm-dev]

Hi Nemanja!

On 10/25/21 11:27, Nemanja Ivanovic wrote:
> Bringing back support for Darwin/PowerPC is of course possible, but such
> undertakings are not free. Aside from the effort to bring it back, there is
> the effort of maintaining that support as the PowerPC back end continues to
> be developed for supported platforms (Linux, AIX, FreeBSD). So in order to
> consider bringing it back, we would really need to understand the use case
> - now and in the future.

I understand. But since both PowerPC and Darwin support are still there, I would
assume that the changes in question aren't big at all. I just had a quick look
and it looks like the majority of changes affects removing tests specific to
Darwin/PowerPC [1] and some minor removal in the AsmPrinter code [2].

I'm not a strong proponent of Darwin but I think those changes are relatively small.

Adrian

> [1] https://github.com/llvm/llvm-project/commit/7c80f98b69a6a9ad027a3f4bfda073958141d977
> [2] https://github.com/llvm/llvm-project/commit/ebd26cc8c434f40fe8079ee823e7657b5138769f

[Andrew Chiw via llvm-dev]

There is a sizable Mac PowerPC community that also thinks that if Rust is on m68k, then it should also be on Darwin PPC, seeing that it's already on Darwin and PPC Linux.

Although speaking with Iain, it doesn't sound like it's actually a trivial matter.

I think the problem is that nobody showed up to defend Rust on PPC Darwin back then (and by extension, Go on PowerPC in a similar GitHub issue) because the cultures are so different. On one side you have devs working deep in large companies and using mailing lists and on the other side you have users on Macrumors/Discord who have no idea how to voice their opinion at crucial times like this.

If someone could onboard me to the scope of this problem in an efficient way, I'd be happy to maintain and also provide docs to make it easy for other devs to jump in and help maintain. Because the main problem here is it's difficult to know what needs to be done, not enough people understand systems programming at a low level to keep things alive for old systems like this. As you know there are so many web devs these days on JS and the like.

I also think it would be interesting to create an economy to incentivize enthusiast development for obsolete platforms. For example, F@H's points system gets people contributing even though they have no monetary value. And there are Patreons for people like Hector Marcan and Rene Rebe. I just think that it should be possible to incentivize and organize an entire community, not just individuals.

But all this will come after a successful port of Rust over...

[Nemanja Ivanovic via llvm-dev]

I am sorry about the delay, somehow I lost this email in my inbox.

While I certainly sympathize with enthusiast developers working on obsolete systems and doing some pretty cool hacking, I agree that the goals of an actively developed back end and an enthusiast-maintained back end are rather different.

Any code for Darwin PPC in the upstream back end is a burden for new development on actively supported platforms such as Linux, AIX and FreeBSD. Similarly, all the new code added for those actively supported platforms as well as new hardware is a burden for enthusiast developers looking to maintain support for obsolete platforms. As such, I believe that coexistence in the same codebase provides little benefit while causing a fair bit of friction. I would suggest that an out-of-tree back end for Darwin PPC would reduce this friction.

While I understand there are definite disadvantages to keeping code out-of-tree due to interface/API changes, I think that these changes are less frequent than the daily interactions that developers for active platforms would have with code that is specific to Darwin PPC.

Nemanja

[John Paul Adrian Glaubitz via llvm-dev]

Hello!

On 11/10/21 14:47, Nemanja Ivanovic wrote:
> While I certainly sympathize with enthusiast developers working on obsolete
> systems and doing some pretty cool hacking, I agree that the goals of an
> actively developed back end and an enthusiast-maintained back end are
> rather different.
>
> Any code for Darwin PPC in the upstream back end is a burden for new
> development on actively supported platforms such as Linux, AIX and FreeBSD.
> Similarly, all the new code added for those actively supported platforms as
> well as new hardware is a burden for enthusiast developers looking to
> maintain support for obsolete platforms. As such, I believe that
> coexistence in the same codebase provides little benefit while causing a
> fair bit of friction. I would suggest that an out-of-tree back end for
> Darwin PPC would reduce this friction.

I fully understand the reasoning and I absolutely agree with you. However, the
the actual changes required to get LLVM to build on Darwin/PPC seem to be rather
minimal, given when we ignore the additional tests which is why I don't think
that Darwin/PPC would actually be such a maintenance burden.

It would be different if there was no support for either Darwin or PPC at all, but
that's not the case. It's more a question of tying to pieces of string together
which are already there.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

_______________________________________________

[James Y Knight via llvm-dev]

On Wed, Nov 10, 2021 at 9:07 AM John Paul Adrian Glaubitz via llvm-dev <llvm...@lists.llvm.org> wrote:

I fully understand the reasoning and I absolutely agree with you. However, the
the actual changes required to get LLVM to build on Darwin/PPC seem to be rather
minimal, given when we ignore the additional tests which is why I don't think
that Darwin/PPC would actually be such a maintenance burden.

It would be different if there was no support for either Darwin or PPC at all, but
that's not the case. It's more a question of tying to pieces of string together
which are already there.

I think there was a lot more behavior specific to the intersection of Darwin+PPC (not applicable to other PPC OSes or other Darwin architectures), than one might think (and than has been mentioned on this thread so far). Fortunately, I don't recall details -- but I rather doubt it'll be such a trivial change to resurrect Darwin PPC support.

Might I suggest installing Linux on old Mac PPC hardware, instead? MacOS 10.5 was the last release able to run on PPC, and hasn't been updated in 12 years.

[ardi via llvm-dev]

On Fri, Oct 22, 2021 at 3:52 AM Andrew Chiw via llvm-dev
<llvm...@lists.llvm.org> wrote:
>
> [...]

>
> What other roadblocks do you foresee? I was under the impression that I
> only need to get LLVM to emit PowerPC MachO, but since then I have also
> heard that I need to get Rust to work with 10.4/10.5's libc... which
> means both language and compiling backend need to have access to the
> 10.4/10.5 libraries... which means I shouldn't try to setup a cross
> compiler with my current state of knowledge. More clarification/context
> much appreciated.

There was a time, far before LLVM was started, when conservative use
of UNIX system libraries was a must in every robust project, so that
you never used "cutting edge" APIs, but just POSIX standard headers.

Unfortunately, the current trend in development is totally opposite to
that. Now, people always use cutting-edge headers, cutting-edge
compilers, cutting-edge language versions (now the trend is that
nothing is cooler than increasing the C++ version required to build
your code). They justify it by saying nobody should use old OSs
because of security, but that's not the real truth (disconnect the
net, and you'll have far more security than the most modern OS). The
real truth, however, is that by requiring the latest cutting-edge
APIs, people buy newer hardware (which let's admit it: it's cool to
unbox a brand-new computer, so few people get angry at that), a new
hardware which by the way is not able to run older OSs, which in turn
gives the (false) impression that the decision to drop support for
older OSs was right. And the wheel goes on and on like that, until
arriving to a point where people accuse you of causing harm to
humankind by using older OSs.

It's a fact that the most modern compiler, linker, and debugger
doesn't strictly need any service not included in POSIX. Extra
requirements are thus artificial, created by the wheel of the trends.
Unfortunately, that's how it works nowadays.

Then, even if you managed to get a 100-people team developing a new
compiler toolchain that required only POSIX, you'll soon face new
problems, because when you'll try to build software with your good
compiler, you'll realize that most applications out there not only
require C++50 to be built, but also new vendor-dependent APIs not
available in your machine).

That's how it works now.

Ardi

[Fāng-ruì Sòng via llvm-dev]

On Wed, Nov 10, 2021 at 6:34 AM James Y Knight via llvm-dev
<llvm...@lists.llvm.org> wrote:
>
>
>
> On Wed, Nov 10, 2021 at 9:07 AM John Paul Adrian Glaubitz via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> I fully understand the reasoning and I absolutely agree with you. However, the
>> the actual changes required to get LLVM to build on Darwin/PPC seem to be rather
>> minimal, given when we ignore the additional tests which is why I don't think
>> that Darwin/PPC would actually be such a maintenance burden.
>>
>> It would be different if there was no support for either Darwin or PPC at all, but
>> that's not the case. It's more a question of tying to pieces of string together
>> which are already there.
>
>
> I think there was a lot more behavior specific to the intersection of Darwin+PPC (not applicable to other PPC OSes or other Darwin architectures), than one might think (and than has been mentioned on this thread so far). Fortunately, I don't recall details -- but I rather doubt it'll be such a trivial change to resurrect Darwin PPC support.

Yes, Darwin+PPC diverge a lot from ELF+PPC.
It had dispatches all over the place which would continuous causing
maintenance burden to folks who are developing the active back end.
The amount of change was more than 2000 lines of code.
For example, I have made these commits in 2020 after the deprecation in 2018:

bfa6ca07a8cda0ab889b7fee0b914907ce594e11 ("[PowerPC] Delete remnant
Darwin ISelLowering code") removed 760 lines.
3e851f4a688c42315355aae743b403dddeba9860 ("[PowerPC] Delete
PPCMachObjectWriter and powerpc{,64}-apple-darwin") removed 397 lines.
7c4555f60d96d8a3ed35d74dab7e591dacc24b8d ("[PowerPC] Delete remnant
Darwin code in PPCAsmParser") removed 118 lines.

> Might I suggest installing Linux on old Mac PPC hardware, instead? MacOS 10.5 was the last release able to run on PPC, and hasn't been updated in 12 years.

Good suggestion:) FreeBSD and Linux are getting updated. I have seen
several folks installing the updated OSes onto the old Mac PPC
hardware.

>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--
宋方睿