Tonight's game on OpenPOWER: ZGloom

We've done some DOS games recently, so for a change of pace let's do an Amiga one. Gloom was a pretty unabashed Doom knockoff using an Wolfenstein-type engine with some map geometry enhancements and transparency and palette effects. I actually have it on my A4000T and it's a bit blocky but plays pretty well with AGA and an '060. You know the drill: marine type guy shoots up other malicious marines, and, um, skinheads, and robots, and then ends up in a Gothic tomb as you do besieged by monsters and ghosts, and then goes to hell, takes the fight to the demons and kills a big dragon to save civilization. Just another day at the office! Its creators made it freely distributable and open-sourced the engine, allowing reimplementations to be made; probably the most developed of these is ZGloom. ZGloom isn't a perfect port — it's missing the title screens, the font and HUD are different, and there are various bugs ranging from trivial to moderate — but it has all the interstitials for what little story there is, has music and sound effects, plays well and does so at high resolution, and has configurable controls with X-axis mouselook. Also, because it's software-rendered, OpenPOWER systems with just the BMC framebuffer can play just fine (it has a multithreaded renderer to take advantage of all those shiny cores we've got). There's no save feature, but ZGloom simply gives you infinite lives, so just keep grinding away with impunity — and while you only have one weapon at a time, you can power it up, so grab all the bouncing orbs you can get for a real supercharge. Doors and switches are triggered by just walking into them, and baby bottles (!) give you health. There are other useful powerups you can find ...

I should also note for the squeamish that Gloom infamously came in "Messy" (temporary gibs) and "Meaty" (permanent gibs) modes, and this port seems to entirely play in "Meaty" mode, which means enemies explode and litter the ground with an alarmingly fast accumulation of body parts. On the original Amiga this would have brought lower-specced systems to their 16-bit knees, but this is a POWER9, so we can have all the fragmented torsos we want. (I have intentionally not shown this in the screenshot.) Don't say I didn't warn you.

Building it from source is straightforward; Fedora 36 has SDL2, SDL2_mixer and libxmp. Before you type make (or make -j24), however, edit the Makefile and add -O3 -mcpu=power9 to the CXXFLAGS. Then download this ZIP of the game resources, unzip it, and copy or symlink the ZGloom binary inside the resulting directory. While you can jump to any level from the main menu, game settings (graphics, keys, etc.) are controlled from the in-game menu after you actually start one.

Now things get serious!

Firefox 105 on POWER

Firefox 105 is out. No, it's not your imagination: I ended up skipping a couple versions. I wasn't able to build Firefox 103 because gcc 12 in Fedora 36 caused weird build failures until it was finally fixed; separately, building 104 and working more on the POWER9 JavaScript JIT got delayed because I'd finally had it with the performance issues and breakage in GNOME 42 and took a couple weeks renovating Plasma so I could be happy with my desktop environment again. Now I'm on track again with everything hopefully maintainable and my workflows properly restored, and we're back to the grind with both those concerns largely resolved.

Unfortunately, we have a couple new ones. Debug builds broke in Fx103 using our standard .mozconfig when mfbt/lz4/xxhash.h was upgraded, because we compile with -Og and it wants to compile its functions with static __inline__ __attribute__((always_inline, unused)). When gcc builds a deoptimized debugging build and fails to inline those functions, it throws a compilation error, and the build screeches to a halt. (This doesn't affect Fedora's build because they always build at a sufficient optimization level such that these functions do indeed get inlined.) After a little thinking, this is the new debug .mozconfig:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-Og -mcpu=power9 -fpermissive -DXXH_NO_INLINE_HINTS=1"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd
ac_add_options --without-wasm-sandboxed-libraries

export GN=/home/censored/bin/gn # if you haz

This builds, or at least compiles, but fails at linkage because of the second problem. This time, it's libwebrtc ... again. To glue the Google build system onto Mozilla's, there is a fragile and system-dependent permuting-processing step that again has broken and Mozilla would like a definitive fix. Until then, we're high and dry because the request is for the generated build file to be generated correctly rather than just patching the generated build file. That's a much bigger knot to unravel and building the gn tool it depends on used to be incredibly difficult (it's now much easier and I was able to upgrade, but all this has done is show me where the problem is and it's not a straightforward fix). If this is not repaired, then various screen capture components used by libwebrtc are not compiled, and linking will fail. Right now it looks like we're the only platform affected even though aarch64 has been busted by the same underlying issue in the past.

The easy choice, especially if you don't use WebRTC, is just add ac_add_options --disable-webrtc to your .mozconfig. I don't use WebRTC much and I'm pretty lazy so ordinarily I would go this route — except you, gentle reader, expect me to be able to tell you when Firefox compiles are breaking, so that brings us to the second option: Dan Horák's patch. This also works and is the version I'm typing into now. Expect you will have to carry this patch in your local tree for a couple versions until this gets dealt with.

Fortunately, the PGO-LTO patch for Firefox 101 still applies to Fx105, so you can still use that. While the optimized .mozconfig is unchanged, here it is for reference:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-O3 -mcpu=power9 -fpermissive"
ac_add_options --enable-release
ac_add_options --enable-linker=bfd
ac_add_options --enable-lto=full
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options MOZ_PGO=1

export GN=/home/censored/bin/gn # if you haz
export RUSTC_OPT_LEVEL=2

I've got one other issue to settle, and then I hope to get back to porting the JavaScript and Wasm JIT to 102ESR. But my real life and my $DAYJOB interfere with my after-hours hacking, so contributors still solicited so our work can benefit the OpenPOWER community. When it's one person working on it, things are slower.

Void PPC goes Chimera (and bust)

Void PPC maintainer Daniel Kolesa has announced that instead of simply phasing out big-endian support in Void in 2022, he will instead cease maintaining the PowerPC/Power ISA fork of Void Linux entirely in favour of Chimera Linux, a fusion of a Linux kernel, musl libc and FreeBSD userland built with LLVM. There may even be a return of support for big-endian, at least for 64-bit Power (32-bit Power to be considered), as well as Chimera's core support for ppc64le, aarch64 and x86_64 (with 64-bit RISC-V coming).

As with the announcement for big-endian, if you like Void PPC and want to maintain it yourself, you can — provided you bring your own build and distribution infrastructure. Otherwise, Void PPC maintenance will end in January 2023. You can try Chimera Linux in the meantime and see how it works for you.

The RAD750's successor looks like it's RISC-V

It's been PowerPC in space for decades, from the Opportunity rover (a 20MHz BAE RAD6000, based on POWER1) to the James Webb Telescope (a 118MHz RAD750 "G3"). These are battle-tested processors in extremely hostile conditions, such as the Juno space probe in orbit around Jupiter where the RAD750 (a 132MHz part with 128MB of DRAM) operates in radiation levels a million times the human lethal dose. As evidence of its performance, it was supposed to be deorbited for destruction in 2021, but was extended to 2025 to examine the inner moons of Ganymede, Europa and Io.

Still, PowerPC never had a monopoly: the European Space Agency uses LEON, which is actually a free and open SPARC V8 core, and NASA has also used MIPS processors such as the 12MHz Mongoose-V (based on the R3000) used in New Horizons, which visited Pluto. A cluster of ARM-based "Rad-Tol Dependable Multiprocessors" (PDF) with OMAP 3503 cores will fly on the 6U CubeSat Lunar Flashlight nanosatellite scheduled for later this year after SLS Artemis 1 got scratched. For non-mission critical components, even some off-the-shelf ARM cores have made it to space; the Perseverance rover is another RAD750 system at 133MHz, but the Ingenuity helicopter drone it deployed was a regular Qualcomm Snapdragon 801.

BAE does have later generation Power parts available today: the RAD510 SOC, a system-on-a-chip with twice the performance of the RAD750, and the RAD5500 family with the RAD5545, derived from the ISA 2.06 NXP e5500. These are all Power ISA, all radiation-hardened, and all available from BAE's Manassas, Virginia facility, a U.S. Department of Defense Category 1A Microelectronics Trusted Source. (The RAD510 core is actually made by GlobalFoundries Fab 10 — one of IBM's former fabs.) With those on the shelf it's a bit puzzling that SiFive announced their X280 (U74-derived) core with vector extensions and AI/ML support will be the heart of NASA's next-generation High-Performance Spaceflight Computing (HPSC) processor instead, or more accurately eight of them (an additional four unspecified general-purpose RISC-V cores round out the total to 12). The chips are being developed on a radiation- and fault-tolerant process by Microchip Technology over the next three years, at a cost of US$50 million. More than just the added processing capability, probably what gives it a greater edge is lower expected power usage on a smaller process size and the ability to shut down silicon blocks for even greater power savings.

It would have to be indeed a significant technical leap to justify a complete break from a well-understood architecture and we'll see soon enough if it's worth it. That said, assuming it accumulates the same stellar track record as the BAE Power parts, the RISC-V HPSC will likely have its own decades-long run in space (assuming Jack Kang, SiFive's idiot senior vice president of business development, can stop smoking crack: there are still more PowerPC programmers than RISC-V programmers even now, chumpcakes). For that matter, the ESA is interested in RISC-V too and we approve of any free computing solution as long as it does the job. But don't cry for Power ISA in space yet; with three years of HPSC development to go, and several critical missions in progress, there's plenty of universe to explore no matter what CPU is doing the exploring. As HPSC will just be one choice of many even at NASA, Power ISA parts are likely to remain part of this very conservative industry for awhile, especially in commercial and military applications.