PowerPC 601 Support Being Retired in Linux 5.10 – The First 32-Bit PowerPC CPU | Hacker News Reader

PowerPC 601 Support Being Retired in Linux 5.10 – The First 32-Bit PowerPC CPU

phoronix.com

61 pointsrbanffy51 comments

I wonder if anyone using Linux regularly ran it on a PPC 601?

Because as a former owner of an Itanium[1] I can say that even when a processor is "officially supported" upstream, unless a critical mass of people actually use it there are lots of weird regressions. Debian/ia64 at the time (2015) only partially worked - lots of common utilities would randomly segfault or fail in peculiar ways.

[1] https://rwmj.wordpress.com/2014/09/08/raise-the-itanic/ https://rwmj.wordpress.com/2015/05/03/raise-the-itanic-part-...

> unless a critical mass of people actually use it there are lots of weird regressions.

Even 32-bit x86 has been having some of those weird regressions these past few years.

Can you provide links to any of those weird regressions?

I don't have anything specific, but until Fedora stopped compiling a i686 kernel altogether a few years ago we had to disable our tests of "does the current kernel boot on qemu" for years on i686 because those kernels simply didn't work. And no one really cared. And no one cared again when Fedora dropped i686 (except for multilib on x86-64) entirely.

The kernel people can say one thing, userland people can say another.

"It compiles, it runs! No smoke tests. libc is busted? oh well, patches welcome!"

I made the same comment above about the kernel. How covered by automated tests is glibc?

How covered by automated tests is the kernel? Some tests would require hardware emulators to some degree, but a lot wouldn't.

Last time I submitted a kernel patch which added some new user-visible API:

  $ grep Umask /proc/self/status
  Umask: 0002

I had to also submit a test to go along with it. I understand that these are run by CI on the main architectures, although it didn't appear to be a condition of accepting the patch that the test was correct on all arches. Also I wonder if their CI really runs on PPC601 and IA64, I guess probably not. (Obviously this minor feature doesn't depend on the arch and it's hard to see how it could go wrong even on IA64).

> Debian/ia64 at the time (2015) only partially worked - lots of common utilities would randomly segfault or fail in peculiar ways.

It works reasonably well these days, albeit not perfect.

There are issues with kernels >= 4.15 on larger NUMA systems, but otherwise it runs mostly fine.

Images can be found here:

> https://cdimage.debian.org/cdimage/ports/

Yeah...I tried to run 68k Linux for a while (quite some time ago, to be fair) and got to "Nope" pretty quick. Your 'critical mass' observation is absolutely spot on: Open Source is about the 'number of eyes on the code', and it turns out you clearly need a certain number of eyes for it to work in the long run.

Well, wasn't the 601 a bit different than the 603/604 in instruction sets? I seem to remember there were some difference from the more refined, later chips.

Yes, some of the ISA was still be standardised so wasn't until the later chips that got ratified, so some nuances, though at hand none I can recall. https://en.wikipedia.org/wiki/PowerPC_600#PowerPC_601 covers this aspect at least.

Also does seem that 32bit support is on the way out, slowly but surely.

Though 32bit will be around for a while in some flavour or another, much like IPv4, it just hangs in there working away.

> Also does seem that 32bit support is on the way out, slowly but surely.

I would be very, very surprised if 32bit support was on it's way out any time soon.

E500 cores are basically 603e, and they don't really seem to be going anywhere.

Killing off the early non standard core that no one has used in decades anymore is one thing, but 32bit PowerPC support in general sounds like crazy town to me.

e500mc is. e500v1 and v2 aren't even user-space compatible because Ruiz-era Motorola was cheap and wanted SMD w/o Altivec, so they replaced the FPU...

They're not user space compatible, but they're very, very similar uarchs as you can tell from the supervisor SPRs.

> e500v1 and v2 aren't even user-space compatible because Ruiz-era Motorola was cheap and wanted SMD w/o Altivec, so they replaced the FPU...

Both run the standard Debian powerpc port with a kernel with FPU emulation enabled.

There used to be a powerpcspe in Debian which I maintained where even Rust worked after I added target support to the Rust compiler (and one very talented FreeBSD developer improved the LLVM backend).

However, GCC upstream decided to kill off the powerpcspe port for GCC 9, so we had to drop it in Debian.

32-bit hardware is still widely produced and deployed. Some desktop-focused distros have dropped 32-bit x86 support but I'm sure the kernel and toolchain will support 32-bit platforms for the foreseeable future. Certainly 32-bit ARM hasn't gone anywhere, and you can't swing a patch cable without hitting a SuperH.

You also have the kernel recently adopting both 32 and 64 bit RISC-V.

> Also does seem that 32bit support is on the way out, slowly but surely.

Nah, we're currently even adding LLVM/Rust support for m68k, so don't worry, 32-bit support isn't going anywhere soon.

Compiling Rust on a m68k machine would demand some patience.

I imagine most would be using it as a cross compiler.

Hopefully.

That's what I'm counting on (looks at his 68030 homebrew board fondly).

from the article.

  "The PowerPC 601 code also requires special handling from the rest of the PowerPC 6xx support still within the kernel, thus it's a maintenance burden."

so yes some differences.

The 601 had support for some POWER instructions that weren’t part of the PPC ISA and weren’t supported by later chips, I know Apple’s developer notes for these machines mentioned that you had to avoid those.

How do these old PowerPC processors relate to the latest POWER10 processors? Is there a recognizable similarity?

Bit like comparing a 8086 to the latest and greatest, still have support for the instructions of the time, but been lots of additions since. At least comparing the ISA level.

Didn’t PowerPC have some unique extensions that distinguishes it from the the POWER CPUs?

Yeah, but Power3 and onward actually implement the PowerPC ISA so the differences are smaller than they appear.

No. Not even remotely close. The 8086 was an 8 bit processor with some 16 bit extensions and segment registers. This is worlds different than 32 bit x86. They're worlds apart.

The PowerPC 601 is functionally quite similar to modern 32 bit PowerPC.

The 8086 was a 16 bit CPU. Every register is 16 bit as is the internal and external data bus (the address space is actually 20 bits, but that's a different issue).

...except it barely more of a 16 bit processor than a Z80, and had 8 bit instructions, extendable to longer, like the Z80. Aside from the 20 bit addressing and 16 bit offset, the 8088 and Z80 were equivalent.

Or should we call the Z80 a 16 bit processor?

> Or should we call the Z80 a 16 bit processor?

Z80 is classified as an 8-bit processor because it has an 8-bit internal data bus to the register file.⁽¹⁾

This is visible in instruction timings: 16-bit INC BC takes longer than 8-bit INC B because the 16-bit register access takes two internal data cycles compared with one internal cycle for 8-bit.

Intel 8086 is classified as a 16-bit processor because it has a 16-bit internal data bus to the register file.

This is visible in instruction timings: 16-bit register operations generally take the same time as 8-bit register operations.⁽²⁾

⁽¹⁾ Trivia: Z80 also has a 16-bit internal address bus and 4-bit ALU.

⁽²⁾ Actually 8-bit INC AL takes longer than 16-bit INC AX, opposite way around from Z80. But that's because of a longer instruction encoding, not architecture. MOV AL,BL takes the same time as MOV AX,BX.)

It's been more than a decade since I wrote any ppc asm and I don't remember much.

I imagine they extended the ISA to 64 bits and maybe that was an opportunity for further ISA changes?

The 601 was pre-standard, so I'd imagine that there would be a huge difference.

It had the first implementation of the multiprocessing unit, and lacked the load/store and registry units of all the later processors.

As far as binaries go you can still target the COM instruction set with the compiler and the same binary will run on any 32/64 PPC up to the latest POWER chips.

I was wondering if someone could come up with a POWER9-based accelerator board for PPC-based Macs.

Obviously niche, but most amusing. Imagine a 48-core 5 GHz MacPro G5.

it'd probably totally be.. possible - to get OS X to boot on a POWER9 system. There seems to be more interest in getting Classic OS to run on modern hardware though

Mac System 9 running on modern hardware, not in an emulator?

Now the web browser can crash the entire system an order of magnitude faster!

That said I love the idea from the perspective of a wonderful hack, but I truly hope no one actually has a use case where running classic Mac OS on modern hardware makes sense.

I'd totally want my Mac work environment running on a dual socket POWER9 workstation.

Not being very familiar with Linux internals, I wonder what these means exactly. Are there ifdefs in the Linux source code specifically pertaining to PPC 601? Or is there some chunk of assembly code in there written for 601 that'll now get dropped?

Interesting chronology for mac/amiga users either way; PPC 601 getting dropped before 680x0.

The remaining 601 users can check out NetBSD, which supports the PPC601 at least as a Tier II port.

Not knowing anything I'm guessing it's all embedded/non-interactive systems, but I can't imagine someone compiling a brand new new 5.9 kernel with drivers for a twenty year old board.

I'm a Linux noob, and I was under the impression that Linux was written in C, and this could be compiled for any architecture, given a compiler with support for it. This really shakes my faith in Linux, if architectures, and even individual CPUs, need to be special-cased in the codebase.

Just kidding. I think I know what's going on here, and it's actually worse than that. Big company (IBM) pushing for tighter integration with their new chips (POWER10), which results in the kernel maintainers having to drop support for their old chip. Why they let a big company bully them like that is beyond me, but I guess something something IBM RedHat Kernel maintainer salaries something. :)

Incredible that this was being maintained.

32-bit PPC ISA is still used in some embedded devices.

We are still actively maintaining support for the Motorola 68000 CPU in the kernel which is even older.

I'd imagine m68k to be in widespread use for industrial applications justifying its maintenance in the kernel.

Since the 68k ISA is still in production I would hope so. But, with all sincerity, thank you since I still use it.

It was an ugly beast, but it will always hold a special place in my heart.

Reply on news.ycombinator.com