[RFC] Removing PowerPC/Darwin Support?

Hi everyone,

I don't believe that anyone is currently using (a recent) LLVM on PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware years ago. There is a significant amount of code in the PowerPC backend dedicated to Darwin support and removing it would make maintaining the rest of the backend easier. If anyone expects upcoming LLVM releases to continue to support PowerPC/Darwin, please speak up.

Thanks again,
Hal

+1.

-eric

The only part I’d like to see NOT removed is the darwin PPC asm format. Not because I care about ppc/darwin, but because that format is like 1000x easier to read – especially for those of us who aren’t PPC experts – than the insane standard PPC assembly format. :slight_smile:

Hi James,

I agree, we should keep a mode that prints register names (instead of just the numbers). I lean toward having a verbose mode that is compatible with the GNU assembler, which means %r1 instead of just r1. gas will also accept that syntax, so it seems more useful than the Darwin syntax on current systems. What do you think?

-Hal

I’m a fan. I find the current syntax to be… difficult :slight_smile:

-eric

I too prefer the sane syntax. Even the IBM compiler would print R's in the .s files (it generated a bunch of defines at the beginning "def R0 = 0", etc.).

-Krzysztof

I did not know that %r1 syntax was accepted by the GNU assembler. Yes – that would be even better!

Wow, end of an era. No concerns from me: someone who cares about building software for old Darwin/PPC machines can use an older version of LLVM.

-Chris

Hi Hal, folks,

I don't believe that anyone is currently using (a recent) LLVM on PowerPC/Darwin.

My current work-in-progress is on 3.8.1 and 3.9.0; following trunk is just too hard for reasons that will probably be evident from the comments below.

I promise to post as clean a version as I can muster to github before the SJ conference (there’s no way most of it’s going to be polished enough to post for review).

As far as I know, Apple stopped supporting PowerPC hardware years ago.

… and, as such, it’s agreed that there’s no commercial justification for supporting it .. but some of us still have several happily working machines (alongside our x86 boxen).

A small point in favour: I will note in passing that powerpc-darwin (certainly on GCC) has habit of exploring ‘corners’ and highlighting bugs that went un-noticed elsewhere. It would seem that there is some merit in diversity of back-ends in this respect.

There is a significant amount of code in the PowerPC backend dedicated to Darwin support and removing it would make maintaining the rest of the backend easier.

I had already spoken with Kit we’d agreed to sit down in SJ and discuss the patch set and how to make things easier for all of us (there are at least a few of the patches that benefit other parts of the port).

If you and Eric could spare 30mins, perhaps we could come up with a list of things that are made ‘difficult’ by the port and perhaps give me some time to address them?

(for example partitioning out the Darwin portions)?

If anyone expects upcoming LLVM releases to continue to support PowerPC/Darwin, please speak up.

I would be sad to see it go, despite that it’s purely an enthusiast’s hobby thing (and it’s not possible to guarantee any particular schedule as such).

Wow, end of an era. No concerns from me: someone who cares about building software for old Darwin/PPC machines can use an older version of LLVM.

unfortunately, this is _not_ the case (and is the underlying reason that supporting it is hard).

The in-tree powerpc-darwin port is incomplete; there are significant chunks of the ABI un-implemented;
in some respects it’s self-consistent, but it won’t interwork with the system ABI for anything other than simple cases.

To make life more interesting, actual system ABI is not fully documented, so one has to deduce it from “see what gcc-4.x does” (this is, shall we say, time-consuming - especially as a hobby activity!!).

However, as of 3.8.0 I have got a pretty solid ABI cover with some wrinkles on bitfields with __attribute__((…)); I strongly suspect some of those wrinkles affect other ports too (but still working through them).

So … right now it’s not a matter of someone maintaining a working in-tree port (my colleague Jon has a box he’s willing to use as a build-bot once we get to the stage of working trunk). Rather it’s a matter of trying to finish off a port on hobby time, against a moving target - which is slow work.

It’s agreed there’s no commercial justification (other than the diversity argument) for keeping it - but I would rather see an engineering solution that solved the maintenance difficulties, instead of just deleting it.

If I’m the lone voice, then fair enough :slight_smile:
… however, I’d be very sad to see the assembler go - I was hoping to use it replace the cctools as (to give access to .cfi_xxxx on ppc to other tools) and for use in wider contexts.

cheers
Iain

I'm struggling to remember ancient history :slight_smile: but I seem to recall that
pure LLVM in XCode *never* supported PowerPC. The Clang front end with gcc
back end did (I think), but never pure Clang+LLVM. Even llvm-gcc was a few
years after Apple stopped making PowerPC hardware.

[I have a few PPC machines I start up from time to time .. two 17" G4
iMacs, a couple of G4 Mac Minis (one I use as a peripheral to an Arduino
:slight_smile: ), and a "MainStreet/PDQ" G3 PowerBook that is my last link to ADB,
SCSI, RS422, floppy disk, analogue modem.]