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.
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.
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.)
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.
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
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.
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.
> 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.
"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."
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.
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.
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.
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).
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.
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.
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.
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. :)
51 comments
[ 2.7 ms ] story [ 116 ms ] threadThe PowerPC 601 is functionally quite similar to modern 32 bit PowerPC.
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.)
I imagine they extended the ISA to 64 bits and maybe that was an opportunity for further ISA changes?
It had the first implementation of the multiprocessing unit, and lacked the load/store and registry units of all the later processors.
Obviously niche, but most amusing. Imagine a 48-core 5 GHz MacPro G5.
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.
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.
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.
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.
Nah, we're currently even adding LLVM/Rust support for m68k, so don't worry, 32-bit support isn't going anywhere soon.
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-...
Even 32-bit x86 has been having some of those weird regressions these past few years.
"It compiles, it runs! No smoke tests. libc is busted? oh well, patches welcome!"
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/
Interesting chronology for mac/amiga users either way; PPC 601 getting dropped before 680x0.
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. :)