Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add opt-in Altivec (ppc7400) architecture #245

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

evanmiller
Copy link

Address macports/macports-ports#11625 with a modest proposal to add a new ppc7400 architecture. The idea is that this Altivec-enabled architecture will be preferred on G4/G5 machines but fall back to regular ppc if not available. When properly implemented in Portfiles, G3 users should no longer see the dreaded incompatible cpu subtype run-time error message.

Support for the ppc7400 architecture is completely controlled by the individual Portfiles, which need to declare support in supported_archs and then pass appropriate configure and compiler flags for Altivec (ppc7400) and non-Altivec (ppc) builds. Existing Portfiles do not require modification (it's OK if ppc builds are secretly Altivec builds), but this PR will provide the tools for maintainers to replace run-time hardware detection with branching on ${configure.build_arch}, or to declare that a port absolutely, positively requires Altivec on PowerPC (e.g. mpg123). See the commit message for a more complete explanation and rationale.

Rudimentary testing performed but I do not have access to a G4/G5, and I also have no idea if universal builds will work here. Earlier, someone suggested supporting ppc + ppc7400 universal builds, which would be a neat trick for binary distributions.

Opening this PR as a draft to discuss the concept and field suggestions. Note that this general strategy might also be used for advanced Intel ISAs (e.g. AVX2 and AVX-512) though that's outside the current scope here.

A number of PowerPC ports bake in Altivec instructions either
unconditionally or via run-time hardware detection (see ffmpeg and
libjpeg-turbo); this either creates unusable builds on non-Altivec (G3)
machines, or inconsistent builds across hardware.

To supply G4/G5 users with Altivec builds without ruining the party
for G3 users, introduce a new ppc7400 architecture. This does not
affect any existing ports; only ports that specifically want to offer
both Altivec and non-Altivec builds need to declare "ppc7400" as a
distinct and supported architecture, e.g.

    supported_archs ppc ppc7400 i386

Once declared, the Portfile can branch on the build_arch, e.g.

    if {${configure.build_arch} eq "ppc7400"} {
        configure.flags-append  --enable-altivec
    }

ppc7400 is opt-in in the sense that the default supported_archs list
does not include it, so this should not complicate existing builds.
Existing "ppc" builds can continue to include Altivec instructions on
the sly, at least until the Portfiles are updated by disgruntled G3
users. It is entirely up to the Portfile to supply appropriate configure
and compiler flags to enable or disable Altivec. (In the future, it may
be worth revisiting this behavior if GCC is capable of generating
high-quality Altivec from unmodified C code.)

The demotion mechanism is used so that G4/G5 machines will prefer
ppc7400 when it is available, otherwise falling back to regular ppc.
@kencu
Copy link
Contributor

kencu commented Sep 11, 2021

The problem I see with this is there are hundreds of ports that run the list of supported arches, branching on the build_arch or configure.build_arch.

ppc7400 is not recognized by any of these Portfiles, and I doubt they want to add specs for this for the 0.0001% coverage it would add.

IMO the simplest thing to do in the relatively few ports that build differently with or without altivec is something like this in the PPC block:

if (altivec available) {
  add_altivec_enabling_option whatever_it_is
} else {
  # clear archive sites forcing a local build should a buildbot someday exist
  archives_sites
}

This presumes only that any PPC buildbot someone sets up would be at least an altivec-capable machine, and we can put that as a requirement someplace if we like. I don't think this is unreasonable at all.

It gets around this theoretical problem very clearly, with minimal disruption, no complicated variants, and minimal added effort in Portfiles.

Many ports already have the first 1/2 of this, and just need the second half added to cover it off.

@evanmiller
Copy link
Author

Just to be clear, ppc7400 is not included in the new default value of supported_archs (see change to src/port1.0/portmain.tcl). So ports that iterate over supported_archs will not see it - or am I missing something? (If ports are iterating over sdk_archs that is a different matter...)

@kencu
Copy link
Contributor

kencu commented Sep 12, 2021

so let's say you set up your G3 system with a build_arch of ppc7400 specified in macports.conf (I assume that is what you mean users to do with this).

And you get to one of the many many ports that iterates over the known build_archs (ppc, ppc64, i386, x86_64, arm64 at present). There is no entry in any of those Portfiles for ppc7400, so the branching logic that branches on the build_arch will fail.

Modifying them all is not reasonable to ask.

The solution I suggest is incredibly simple and unobtrusive, and solves the problem fairly elegantly (with the proviso that a PPC buildbot would have to be a G4 or better). It seems so much simpler to me to do that.

@kencu
Copy link
Contributor

kencu commented Sep 12, 2021

Sorry I guess I had it backwards. G3 users you propose would leave their build_arch as the default ppc, and anyone with a G4 or G5 be asked to set their system up with ppc7400 in macports.conf to get altivec? Perhaps I am not fully following how this might work transparently without any changes in any portfiles.

I still think clearing archive_sites on G3s when needed is a very simple solution to the issue though.

@evanmiller
Copy link
Author

ppc vs ppc7400 is now auto-selected (via [sysctl hw.vectorunit]) in src/macports1.0/macports.tcl – no changes are needed to anyone's macports.conf.

The idea is that ppc is a fall-back architecture for ppc7400, just as i386 is a fallback architecture for x86_64 (and ppc is a fallback for ppc64). Ports iterating over build_archs should not see ppc7400 unless they explicitly put ppc7400 into their own supported_archs.

If you can point me to an example of a Portfile that you think will need modifying I will be able to understand your concerns better.

@kencu
Copy link
Contributor

kencu commented Sep 12, 2021

Reading it over some more, I see what you mean.

I think it could be made to work -- like arm64 was made to work -- as it is, I'm not sure about things like the muniversal PortGroup and ports that iterate over the folders in there of various archs, or meson with it's universal enhancements I added, etc, etc. None of those consider ppc7400 as an arch to work with. So it could be made to work, but I think pitfalls still seem likely.

It's clever. I continue to push for the practical simplicity of clearing archive_sites on G3s for the few ports that build differently with altivec, as -- to be honest -- there is likely not much enthusiasm for taking on such a project to support G3s when a simpler alternative is readily available.

PPC usage in MacPorts as a whole is a very tiny portion of the user base -- you may well be the only active G3 user we have. There is only so much effort to be expected to support that base.

I am just now in the process of switching several of my G5s over to Debian 10, which has some future as an OS.

@evanmiller
Copy link
Author

Yeah I was afraid that the universal stuff may prove the downfall of this approach.

Hardware checks in a Portfile make me wince a little bit – but only a little, and I'm fine with your solution if I/we can sell it to MacPorts. The other discussants didn't seem too keen on it.

The separate architecture outlined here seems "right" to me – but really I just want to be able to port install libjpeg-turbo on a G3 on not have it barf on me at run-time. I'm fine with either approach, but mainly just want a clear policy in place so that I know how I should be fixing ports to run on G3s.

@mascguy
Copy link
Member

mascguy commented Oct 28, 2021

I'm blessed with two PPC Macs - a 2001 iMac G3, and a 2004 PowerBook G4 (with a 7450, I believe).

So if you need any additional help testing these changes, let me know!

@evanmiller
Copy link
Author

So if you need any additional help testing these changes, let me know!

Thanks! I'm going to let this one sit until the individual ports are working on G3 and there is a cross-compilation story that needs addressing. libjpeg-turbo and OpenBLAS seem to be the last hold-outs.

@hamishmb
Copy link

hamishmb commented May 1, 2022

I have an iBook G4 that I'm willing to use to test stuff for you if it is still needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants