Hacker News Reader

Comment by weland | Hacker News Reader

Linkbait much? Further down below, Torvalds explains precisely why BE is anything but dead. All that's dead is general-purpose CPUs using it, mostly because x86 happened.

http://geekandpoke.typepad.com/geekandpoke/2011/09/simply-ex...

(Edit: which is precisely why I prefer BE for anything, unless there is a pressing - usually hardware- and performance-related - requirement for the opposite. Computers are good at reading bytes in swapped order. I suck at it.)

View on HN

I think Linus' comment is more on the lines of picking an endian-ness and sticking with it rather than having to check the specific stream and swap bytes conditionally.

He specifically mentions cases where the data is stored in BE and the program reads it, swaps it, operates with it, swaps it back again and writes it.

The BE comment seems to me to be of much less importance than the other message (kind of like a side comment). And as you say, BE is very much alive today.

Absolutely. Encoding byte order and swapping or not swapping dynamically is a silly solution to a problem no one had in the first place.

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.

SPARC is also big endian.

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.

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.

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.

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.

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.

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...

"Computers are good at reading bytes in swapped order. I suck at it."

Byte endianess is about binary content, which isn't supposed to be read by humans. Humans read only interpretations of the binary data. You shouldn't come nowhere near to the question of if you are or aren't good at reading binary.

Let me guess, the software you write runs on desktop computers, web servers and such?

od -t x1, much?

As somebody who had to generate and read back tokenized files decades ago, I can vouch that little endian sucks.

>Byte endianess is about binary content, which isn't supposed to be read by humans.

You can tell a lot about someone's programming history from statements like this.

Anyone who habitually works on low-level code has plenty of experience working with raw binary data.

Working with raw binary data, like having it represented as hexadecimal pairs per byte? That is an interpretation. Having some representation for each bit in the group is still an interpretation, regardless if you consider those bits individually or in groups forming masks. "Reading" that binary content is by representing it in some form or another and interpreting it as such. Like I said, humans read interpretations of that binary data.

P.S.: You are a bad judge of characters. I worked on low-level code (microcontrollers programming, for a living).

Well, reading the hexadecimal interpretation of a memory dump full of little-endian data is annoying as fuck.

Although I believe your sentiment, I'm not sure on the other hand how much easier it appears to you with BE dumps. Reading data is perceived to be difficult when it shares little similarity with what we're already accustomed to. In time it will become more familiar, especially when you'll do a lot of it.

I've done enough of it that I hate it routinely, rather than occasionally.

Initially I disagreed with you until I thought about it for a second and realized Hex was technically an interpretation as well. You're mostly right, although I do think calling hex an interpretation is maybe not completely accurate. It's accurate enough, but I could see someone arguing the other way.

But regardless, I agree that no one is really going to be looking at raw binary. Atleast I can't think of a good reason why anyone would.

Reply on news.ycombinator.com