6 ms·
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
by weland 11y ago
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-explained-1.html 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.)
- justincormack 11y agoWell, 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.
- aduitsis 11y agoSPARC is also big endian.
- bandrami 11y agoIBM 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.)
- vonmoltke 11y agoI 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.
- bandrami 11y agoI'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.
- vonmoltke 11y agoThat 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.
- duskwuff 11y agoThe 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.)
- bandrami 11y agoSorry, 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.
- weland 11y agoIn 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.
- JoeAltmaier 11y agoWhich is the great tragedy of our age. What a colossal waste
- smorrow 11y agoIt'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...
- JoeAltmaier 11y agoThe 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.
- smorrow 11y agoAny 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.
- JoeAltmaier 11y agoThe OPs point was, there are essentially no more BE boxes.
- limeyx 11y agoNot for networking...ntohl/htonl and friends are no-ops (macros) on BE machines ... zero overhead
- eliben 11y agoPowerPCs are still 32 bit though, and fairly popular in the uController space [http://en.wikipedia.org/wiki/PowerPC http://en.wikipedia.org/wiki/PowerPC]
- vonmoltke 11y agoPOWER != 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.
- Shivetya 11y agoOdd, 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.
- jk 11y agoThere 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.
- StillBored 11y agoAnd 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...
- loopbit 11y agoI 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.
- weland 11y agoAbsolutely. Encoding byte order and swapping or not swapping dynamically is a silly solution to a problem no one had in the first place.
- restalis 11y ago"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.
- jpindar 11y agoLet me guess, the software you write runs on desktop computers, web servers and such?
- Roboprog 11y agood -t x1, much? As somebody who had to generate and read back tokenized files decades ago, I can vouch that little endian sucks.
- wyager 11y ago>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.
- restalis 11y agoWorking 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).
- weland 11y agoWell, reading the hexadecimal interpretation of a memory dump full of little-endian data is annoying as fuck.