The POWER/PowerPC ISA is still widely used in safety-critical avionics, where a mature tool-chain exists for supporting DO-178 objectives.
In my opinion, an area of interest going forward into the next decade of more safety-critical software written by smaller and smaller orgs (e.g. eVTOL companies, sensor companies, etc) is continuing to push forward which objectives can be accomplished by formal means instead of primarily through testing.
An NXP or IBM processor might be great, and might be mature, and might be very well tested -- but I, as a safety-critical software developer, have little way of demonstrating that to certification authorities. The availability of open-source processor designs and, in the future, traceable and accountable conversion from those HDL designs to RTL, to masks, and then to silicon, gives a path to showing that portions of a processor are correct-by-design, and thus a path to the goal of showing that my machine-code-as-authored(-by-an-assembler) and machine-code-as-executed(-by-a-processor) semantics match.
I'm not familiar with whether the 737 Max development used DO-178B or DO-178C; the latter is a successor to the former, but frames the development process significantly differently.
Any process can be used well or poorly, and DO-178C isn't really a process, it's a set of objectives that a process must accomplish. When used in good faith, I believe it can lead to software of higher quality than almost any other approach (although, to be fair, at higher software development cost than almost any other approach). That doesn't mean that chanting the document name and using hand-me-down rituals is sufficient to achieve high quality software, of course :-).
Many hyperscalar server setups use POWER8/POWER9 CPUs. 4 logical processes per core (and 8 with the upcoming 15-core POWER10 configurations) are pretty useful when measuring perf-per-watt.
The Talos is currently the only fully libre computer available for high-perf computing, and it uses POWER9 CPUs. If you want a fully free CPU, your choices are either very dated CPUs or POWER.
Many distros (inc. Debian, and most source-based ones) support ppc64/POWER officially quite well and go out of their way to ensure a high degree of portability.
Actually, SMT8 P8 and P9 is documented, though it seems rare. Our HPC systems are only SMT4, anyhow.
Yes, you can just install most of at least Debian, Fedora, RHEL, at least, though it needs an "alt" kernel on RHEL7 P9. There are a few things which haven't been ported, mainly due to assembler, I guess. (PRoot and DMTCP are two I know.) Even x86 SIMD intrinsics will largely work, if not necessarily very efficiently.
we'll be going as far as is practical and pragmatic with the actual hardware, and still actually meet user-expectations. firmware, bootloader, OS, drivers, BIOS: definitely.
AFAIK this is a libre soc developed using libre software tools, some of which were developed by the group members themselves, free from royalties and independent from any for-profit institution. This is probably "librier" than RISCV.
IMO: the underlying architecture is mostly relevant to kernel/compiler authors and people doing aggressive optimization. For most application devs it's about as irrelevant as you can get (unless your language has a very hard to port compiler cough rust.)
What's good about this is that the source is available and can be verified to some degree against the hardware (by decapping it.) That puts a log of constraints on what kinds of secret back doors people can build that we didn't have before.
Rust supports powerpc64le-unknown-linux-gnu, it is in-fact what we used to test a lot of POWER9's instructions to replicate the exact results that POWER9 gives, since the ISA spec doesn't specify the results for a lot of cases.
ultimately what we'd like to see is entirely NDA-free PDKs even for 12nm and below, and you can run the VLSI tools and generate the EXACT GDS-II yourself, then yes, de-cap the processor and do a digital comparison.
before you even get to that stage, you run the Formal Correctness Proofs and unit tests on the HDL, so that YOU have confidence that the HDL which you're about to generate the GDS-II files from is actually correct and does the damn job.
example of a Formal Correctness Proof for the fixed arithmetic Power ISA pipeline:
runs with symbiyosys, so you end up running SAT Solvers like yices2 and z3.
basically we absolutely do not want to be the people you come to and say, "can we trust your ASIC?" and like Intel they lie to you and say "of course!", we want to say, "don't bloody well ask us, go run the damn tools yourself! oh, btw, if you want help with that we charge USD 5k per hour"
