To answer both uunix and countzero: yes, it is designed to run Linux, and my unit will be running Linux (probably Debian ppc64le). I would be very surprised if the *BSD guys didn't come up with a port, though, given that the hardware is open stack.

As far as x86 goes, it would be purely software emulation, but QEMU does at least have some dynamic translation capability. The endianness matches, so that's some small improvement.

Yup, POWER9 is LE as well as x86, but PowerPC and POWER machines have a special hw instruction which translates a word from BE to LE and LE to BE, and It takes just one clock cycle. It's not a penalty.

ClassicHasClass wrote:To answer both uunix and countzero: yes, it is designed to run Linux, and my unit will be running Linux (probably Debian ppc64le). I would be very surprised if the *BSD guys didn't come up with a port, though, given that the hardware is open stack.

As far as x86 goes, it would be purely software emulation, but QEMU does at least have some dynamic translation capability. The endianness matches, so that's some small improvement.

I'll probably try to push for the BSDs to support it. I've got some ideas in the pipe as soon as I get the pressing issues off my plate.

You could, as well, if you wanted, boot a big endian lightweight Linux distro and try Mac-On-Linux. I'd give it a shot, at least.

Does the move to a Talos box mean anything for your Apple hobby programming?

Yup, POWER9 is LE as well as x86, but PowerPC and POWER machines have a special hw instruction which translates a word from BE to LE and LE to BE, and It takes just one clock cycle. It's not a penalty.

I'm well aware of this because TenFourFox uses those series of instructions (lwbrx, stwbrx, etc.) to emulate little endian typed arrays, and you're right that there's no penalty which allows that hack to work as well as it does, but applications have to be compiled to specifically do this or they'll just use native endianness (lwz, stw, etc.), so you still need software changes; it doesn't "just happen." The G3 and G4 had a very fast means of automatically treating areas of memory as little endian which was used most notably in VirtualPC, but this is not universal to the PowerPC line (the 604 and the G5 don't have it, for example).

The point is, now you don't have to worry about it, and software should "just work." I personally prefer big endian because it's how I "think" but that battle was lost years ago. And hey, the 6502 is my favourite CPU and it's little endian, so.

p.s.A good and useful application to be ported to linux/PPC64 is OpenSCAD; it's a programmable Solid 3D CAD Modeller. It requires things like eigen, qtcore, qscintilla, glew, cgal, opencsg, which are all great clock cycles consumers as well as the C++ numerical library involved in the application, but this CAD is very useful for STL modelling, and it can be used to design interesting parts like the engine propellers of my ROV. It's also interesting because you can model parts with scripts.

Do you also plan to test the read/write performance of two M.2 SSDs in PCIe adapters in your G5? All PCIe ports in the Powermac 11,2 models seem to have at least 4 lanes (everymac.com states 2 x PCIe x4, 1 x PCIe x8 and 1 x PCIe x16). So each could theoretically yield 1 GiB/s for reads and 1 GiB/s for writes. And even a single "good" M.2 SSD should outperform SATA SSDs easily. Would be interesting to see, what performance levels your G5 could reach with such SSDs.

ClassicHasClass wrote:The G3 and G4 had a very fast means of automatically treating areas of memory as little endian which was used most notably in VirtualPC, but this is not universal to the PowerPC line (the 604 and the G5 don't have it, for example).

The point is, now you don't have to worry about it, and software should "just work." I personally prefer big endian because it's how I "think" but that battle was lost years ago. And hey, the 6502 is my favourite CPU and it's little endian, so.

I've always wondered why IBM dropped the feature on the G5. It took a while until Microsoft updated VirtualPC and performance was not that great. Some things ran better on a MDD than they ran on the G5 if I recall correctly.

We inherited little endian due to x86's massive success, but I wonder why architectures went little or big endian in the beginning.Big endian seems to be logical, specially if you are reading memory dumps. =p

johnnym wrote:Do you also plan to test the read/write performance of two M.2 SSDs in PCIe adapters in your G5? All PCIe ports in the Powermac 11,2 models seem to have at least 4 lanes (everymac.com states 2 x PCIe x4, 1 x PCIe x8 and 1 x PCIe x16). So each could theoretically yield 1 GiB/s for reads and 1 GiB/s for writes. And even a single "good" M.2 SSD should outperform SATA SSDs easily. Would be interesting to see, what performance levels your G5 could reach with such SSDs.

Initially, I planned to get the best M.2 SSDs I could afford. But I keep a stable monthly budget for playing around and I was afraid of going that way, having compatibility issues and then losing money. I have a few projects running in parallel and investing too much into this one would delay the others. At some point, I planned getting a GeForce 6600 to have three PCIe slots available and see how fast I could go, but reason ended up speaking louder.

Once I'm done with my new NAS and replacing three Cisco routers with Banana devices, redoing my VPN and having the G5 in a final stable configuration, I plan to revisit this as academic curiosity, even if I end up selling the parts later for a loss. You know, for the science. M.2 SSDs could end up in my NAS as caches as well.

The G5 is my main box, so I can't afford having too much downtime for playing around.

Shiunbird wrote:We inherited little endian due to x86's massive success, but I wonder why architectures went little or big endian in the beginning.Big endian seems to be logical, specially if you are reading memory dumps.

They were conventions used in closed corporate cultures. IBM always used big-endian numbering, and DEC always used little-endian.

The more I work on the metal of the G5, the more it's clear it was a hurry-up job on IBM's part to pacify Apple. It is the only Mac that uses PowerPC v2.0 encoding (that means at-bits on branches instead of y-bits, meaning every piece of software that had branch hints suddenly didn't have them on the G5) and the only Mac that uses dispatch groups for scheduling, and it is missing at least one PowerPC instruction that is just plain not implemented even though it's marked as non-optional in the spec (most notoriously |mcrxr| but I wouldn't be surprised to find others). And, as pointed out, it is completely lacking the G3 and G4 pseudo-little-endian mode. All of these things had to be worked around in software (as Microsoft did for VPC and as I do for TenFourFox) or in the OS.

The reason is simply because IBM took a POWER4 core off the shelf, stretched out the pipelines to boost the clock speed and bolted on the AltiVec design they still had sitting around from the 7400. And it shows: the 970 has far more in common with server POWER chips of that era than with any categorical PowerPC chip that preceded it. But it had massively better bandwidth and could be clocked really high, so if you could deal with the TDP it would stomp the G4 flat. And it did. Think of it as the PowerPC's NetBurst.

So the reason it isn't there is the chip was already way too complex and way too hot and Apple needed it way too quickly, so IBM just phoned it in. Adding that feature would have been too costly in design time and die size. A far better G5 would have been a 7450 with a better FSB and maybe some extra cache, and while they're at it to stretch the pipeline a little to ramp it up for the marketdroids. But Motorola wasn't interested in building such a thing and IBM wasn't interested in making a successor to a Motorola design.

Don't get me wrong: I really like my Quad, and I'll never ditch it. But I think the G5 had a lot of missed opportunities, and most of them was because Apple demanded too much and IBM gave them too little.

FWIW, VPC on my Quad runs well enough, but I like the older VPCs, especially on OS 9 where they can just run flat out. VPC 3 I think was the pinnacle for DOS and Win9x gaming.

The more I work on the metal of the G5, the more it's clear it was a hurry-up job on IBM's part to pacify Apple.

Do you feel its a poor implementation then? I've always wanted one of the quad G5's, but I wonder if getting one of the IBM systems would be better. I have no Mac OS requirement, and my use would be purely linux development.