▲ 98 points
back
23 comments
I like their description of r0 as "limited use." There was some parody Twitter account with "new PowerPC instructions," one of which was mscdfr0 -- Means Something Completely Different For Register 0. See https://twitter.com/ppcinstructions for others (I'm not the author).
For those who don't get the joke, certain instructions like addi r0,r0,1 (encoded as addi 0,0,1) actually get turned into addi r0,0,1 -- instead of adding one to the contents of r0, they add one to zero, putting one in r0. This is to facilitate loading immediates, so a typical "load32" does an addis (same r0 limitation) to load the upper 16 bits followed by an ori (doesn't) to load the bottom.
This is maddening if you don't watch what you're doing, which is why RISC architectures that make a register explicitly always zero are sometimes less obnoxious (MIPS).
The article is, however, disingenuous about branching. Virtually any PPC (dis)assembler worth its salt will use extended mnemonics for the bc instructions the author complains about. Plus, you can branch on arbitrary bits in the condition register fields, which the bzero32 routine in Mac OS X uses to great effect (mtcrf 0x01,r4 puts the lower four bits into the condition field, and then it just tests each individual bit with a bf branch -- no compares needed!).
Old MacDonald had a PowerPC, eieio...
https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_...
...I also liked instructions like rlwinm and stfsux. There was no "stfu" but it does sound plausible...
r0 was 0 only for addi/ addis and as rA=0 in EA calc for load/store, so you got 32 registers to store things into. The assembler should have implemented the simplified mnemonics.
addis/addi was the suggested way to load a 32-but value in the Compiler Writer's Guide to take advantage of some mythical 3-input adder hardware, but was there ever an implementation that actual had one and a fetch/issue that supported it? Not in 603/604 afaict.
ETA: [stuff about mtcr serialization which I misremembered.] The early stuff had low penalty branch mispredicts, so you would just do andi. or cmpi and however many branches.
SPR numbering included non-problem state (privileged) registers. That's why it's sparse looking from user space.
> The article is, however, disingenuous about branching. Virtually any PPC (dis)assembler worth its salt will use extended mnemonics for the bc instructions the author complains about.
I sort of got that from the article, though: The official PowerPC assembly syntax is confusing, so (dis)assemblers added some extensions to make it more readable/writable. E.g.: "This is ridiculously confusing,² so nobody uses the purely numeric names. People call them r0 through r31. (Some assemblers call them r.0 through r.31.)"
The official syntax in the spec describes "Extended Mnemonics" including the sane bc aliases.
Ah, so it was provided by Power itself, I see. Thanks!
I am sorry for game and compiler developers.
or is there any other group that cares about this today?
If you want to get really skilled at debugging, symbolic debuggers often break down in ways that are easily worked through by reading disassembly. Reverse engineering is a related and more elaborate extension of that. Finally, certain types of development are done partially with native use of the ISA even if the majority is done in a higher level language like implementing atomics and related lock free algorithms, bootstrap code for systems software, multimedia and compression codecs. It's useful and only a few days learning to have at least passive familiarity in the main ISA you use if you do anything that compiles down to native code for the first reason. It's also not that bad, I'd rather read assembly over modern javascript frameworks to be perfectly blunt.
most of the time I had to gdb something that was broken (apache on all my last times) I was looking for IO instruction at the wrong time instead of bugs in pointers usage, but yeah, I do see your point (no pun intended). I can clearly see eioio causing some of the performance/race conditions I was hunting down recently (which thankfully was NOT on ppc :)
a tiny, faint silver of a percent of all game developers would ever need to write assembly code these days, PPC or otherwise.
Even on low-end phones you can safely use c.
I hope this series goes into the fabled 615. A Pentium socket compatible PowerPC chip that also had a x86 instruction decoder, but was never released.
The 615 got a lot of bad press and much of it was not deserved. There was that apocryphal claim it took an "eternity" to mode-switch, but while the penalty was non-trivial (a pipeline spill), it was definitely faster than claimed. This was probably no small amount of FUD on Microsoft's part so that they wouldn't have to support it.
The real irony was the existence and support of Windows NT on PowerPC (up to the W2K betas), so Microsoft actually didn't have much of a beef with supporting the architecture in general after all; they just didn't think doing the engineering on the 615 specifically was worth the cost.
Microsoft dropped support for NT 4 PPC in 1997, very early in the release cycle. SP2 was the last update that had PPC support. Maybe you're thinking of Alpha, that was much better supported and was only dropped during the Win2K RCs.
https://www.itprotoday.com/windows-8/windows-nt-powerpc-no-m...
Ah, yes, I was thinking of Alpha. But NT4 was still a full fledged product on PowerPC at least for a period of time, so my larger point stands.
The Microsoft and IBM back and forth will forever be a defining characteristic of the history of computing. It's almost a shame they haven't played a good round in a while, but that seems as much of anything IBM's search for relevance post-"We're just a consulting firm, and maybe Cloud, something, something, everything is 'Watson' now".
Microsoft didn't do much or any work to support PowerPC, actually. It was mostly paid by Motorola, which created a team in Austin to do the port, to be sold for their PowerStack machines:
https://www.computer.org/csdl/proceedings/cmpcon/1994/5380/0...
I remember rumours that Motorola also paid Microsoft money for the privilege of doing all the work.
Learn something new every day. Thanks!
> An operating system running on PowerPC 615 could either chose to execute 32-bit or 64-bit PowerPC instructions, 32-bit x86 instructions or a mix of three.
And to think people complain about the number of ARM instruction sets :)
These are enormously important processors, the 604 and 620 were invariably checkpoints of modern CPU design to the masses.. OoO, hardware performance counters etc.
Not sure why Microsoft is writing about PowerPC 600 now, other than some technical insights, anything else interesting? I feel PowerPC is gone, along with UltraSPARC, HP, SGI, etc chips.
PowerPC as a trademark is, but given that modern Power ISA implements almost all of it and then some, the architecture is hardly "gone."
There's still a lot of Power chips in the embedded space and high end server hardware, and there are also boutique systems like the modern Amiga (mostly embedded chips) and the Talos II (POWER9).
This is Raymond Chen’s blog, who has been writing interesting technical articles, including multiple detailed introductions of past and present architectures, for more than a decade (maybe even longer). Some of the covered architectures are gone entirely, some have changed since their presented form. That’s a big part of what makes them so interesting.
Raymond celebrated 15 years of blogging about Windows history and related topics recently (July 20)
https://blogs.msdn.microsoft.com/oldnewthing/20180720-00/?p=...