Hacker News Reader

Comment by justincormack | Hacker News Reader

Well, and IBM switched Power to little endian recently (the machines are dual endian, but all the new OSs are littl endian only). Power was the main BE architecture left. Most arm machines are dual endian, and NetBSD supports both, but almost everyone uses little endian on arm. There is a bit of big endian mips around still, eg the Cavium network appliances.

View on HN

In the meantime, almost every bytestream sent over networks on planet Earth is BE, regardless of whether it's sent by or to a LE or BE machine.

Which is the great tragedy of our age. What a colossal waste

It's the same C code doing IP, going through the same steps and the same number of steps, whether the underlying machine is little- or big-endian. So if you're saying about wasted cycles...

The waste is every little-endian machine (almost all machines) converting every packet to big-endian for 'the wire', then converting back again when received. Its all a pointless self-flagellation.

Any sensible code is going to have to do that stuff whether the machine's endianness matches IP's or not, though. It happens on BE boxes too. It's either that or write completely different code for different CPUs.

The OPs point was, there are essentially no more BE boxes.

Not for networking...ntohl/htonl and friends are no-ops (macros) on BE machines ... zero overhead

> What a colossal waste

How expensive do you think endianness-swapping is?

<http://www.agner.org/optimize/instruction_tables.pdf>

About 1 clock cycle per word.

Fixed link:

http://www.agner.org/optimize/instruction_tables.pdf

Miniscule multiplied by massive.

Expensive in having to do it at all - code complexity, confusion between HBO and NBO buffers, heck the fact that nobody can even receive an opaque packet at all! You have to know every field to correctly normalize it on receive. This impacts code at every layer of the network.

Shuffling bits around takes basically zero effort, there's often a CPU instruction to flop them. Re-doing everything to be the opposite polarity takes tons of effort.

And while it was probably a "good" idea, the implementation was terrible. Absolutely zero binary compatibility between SLES11 on a POWER7 and SLES12 on a POWER8 (same for RHEL). I think the official line was that compatibility comes in the form of being able to run the older OS in a VM...

This is worse than the HP-UX PA to IA transition, the mac 68k to PPC, or PPC to x86, transition/etc.

The least they could have done was some kind of elf loader, and some fat libraries that flips the execution mode for one generation while everyone transitions.

The stated claim was to make it easier for people to transition to POWER from x86 (aka little porting effort), but what they really did was screw their existing customers by requiring them to port their software (big porting effort). I question, why if I'm going to spend the effort to port from BE POWER to LE POWER why I wouldn't just port to x86...

IBM also for years screamed at devs that you can't rely on a PPC system being BE. Which means all oldworld MacOS software was at least theoretically written by people who couldn't tell you what byte order they were writing for. (How seriously the devs took that admonition is a different question.)

I was writing real-time signal processing software for POWER as recently as three years ago. I'm not even aware that was IBM's position, and they were our partners on the venture.

That said, it really didn't matter because all our software had to build and run on x86-64 anyway, so all the endian-specific code was wrapped in preprocessor directives. We could have changed the endianness with a single makefile change.

I'm not even aware that was IBM's position

Yeah, I said it badly. IBM wouldn't guarantee Apple that Power would always support BE, so Apple pushed (or tried to) developers not to assume that.

That makes sense. IBM knew we were focused on the POWER7 blades and that our backup plan was their Intel blades, so they probably figured the warning wouldn't be relevant to us.

The PowerPC architecture was bi-endian, but classic Mac OS was very definitely big-endian. The only situation where the CPU would switch to little-endian would be if it was running Virtual PC. (And even then, it'd switch back for other applications.)

Sorry, yeah, I stated that badly:

Apple kept screaming at devs that IBM couldn't be guaranteed to keep the arch bi-endian, so Apple couldn't guarantee a big-endian platform and developers shouldn't assume one.

SPARC is also big endian.

PowerPCs are still 32 bit though, and fairly popular in the uController space [http://en.wikipedia.org/wiki/PowerPC]

POWER != PowerPC. POWER processors through the POWER4 generally implemented the PowerPC ISA, but were not "PowerPC" chips. Also, there is a 64-bit PowerPC ISA; that is what the POWER4 implemented. It just doesn't get much use in embedded contexts because it isn't necessary and costs more.

There are quite a few big endian MIPS devices. Many Chinese processor vendors (Mediatek, Rockchip, etc.) still use MIPS and have big endian configuration. Most common are TV SoCs and networking chips like WiFi SoCs.

Odd, iSeries and pSeries are BigEndian, even Z is.

On the iSeries it has no bearing on application programmers except when using transformation products to other platforms.

Reply on news.ycombinator.com