Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Endian wars and anti-portability: this again?

dalmatian.life

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Endian wars and anti-portability: this again?

#51

Post by Joker_vD »

zephen wrote: post #28
yjftsjthsd-h wrote: post #22

Earlier quoted context omitted.

No, BE is logical because it puts bits and bytes in the same order. That humans use BE is also nice but secondary to that. I don't have strong feelings about whether fifty-one thousand nine hundred sixty-six is written as 0xcafe or 0xefac, but I feel quite comfortable suggesting that 0xfeca is absurd. (FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use i…

Your example is only for dumping memory. > this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it Computers really don't care. Literally. Same number of gates either way. But for everything besides dumping it makes sense that the least significant byte and the least significant bit are numbered starting from zero. It makes intuitive mathematical sense.

> Computers really don't care. Literally. Same number of gates either way.

Eh. That depends; the computer architectures used to be way weirder than what we have today. IBM 1401 used variable-length BCDs (written in big-endian); its version of BCDIC literally used numbers from 1 to 9 as digits "1" to "9" (number 0 was blank/space, and number 10 would print as "0"). So its ADD etc. instructions took pointers to the last digits of numbers added, and worked backwards; in fact, pretty much all of indexing on that machine moved backwards: MOV also worked from higher addresses down to lower ones, and so on.

Re: Endian wars and anti-portability: this again?

#52

Post by userbinator »

zephen wrote: post #28
yjftsjthsd-h wrote: post #22

Earlier quoted context omitted.

No, BE is logical because it puts bits and bytes in the same order. That humans use BE is also nice but secondary to that. I don't have strong feelings about whether fifty-one thousand nine hundred sixty-six is written as 0xcafe or 0xefac, but I feel quite comfortable suggesting that 0xfeca is absurd. (FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use i…

Your example is only for dumping memory. > this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it Computers really don't care. Literally. Same number of gates either way. But for everything besides dumping it makes sense that the least significant byte and the least significant bit are numbered starting from zero. It makes intuitive mathematical sense.

Same number of gates either way

Definitely not, which is why many 8-bit CPUs are LE. Carries propagate upwards, and incrementers are cheaper than a length-dependent subtraction.

Re: Endian wars and anti-portability: this again?

#53

Post by ozgrakkurt »

dataflow wrote: post #31

The whole thing rests on these assertions: > It is usually easy to write code that is endian-safe. Any code that is not endian-safe is poorly written and harder to maintain at best, and possibly obscuring security bugs at worst. Any project maintainer should be jumping for joy when they receive a patch adding a big-endian port of their project, especially if it includes reports that tests pass and the software works.…

Main issue I have with it is access to testing. It is extra work to be able to test big endian. I don’t want to think about big endian while writing code but it would be ok to do it if I could easily run tests in big endian.

Re: Endian wars and anti-portability: this again?

#54

Post by rcxdude »

sparkie wrote: post #42

Reminder that the computer's endianness shouldn't matter. You should only care about the endianness of the streams your reading from and writing to. https://commandcenter.blogspot.com/2012/04/byte-order-fallac...

This. In the specific case of endianness, if you have bugs with it you're probably already doing something wrong. But in general, supporting weird architectures is not something that should be expected to be foisted on any arbitrary projects, especially if the person who does the initial port just disappears again.

Re: Endian wars and anti-portability: this again?

#55

Post by adrian_b »

yjftsjthsd-h wrote: post #14
userbinator wrote: post #9

If you want to keep software working on systems with a 9-bit byte or other weirdness, that's entirely on you. No one else needs or wants the extra complexity. Little endian is logical and won, big endian is backwards and lost for good reason. (Look at how arbitrary precision arithmetic is implemented on a BE system; chances are it's effectively LE anyway.)

> Little endian is logical and won, big endian is backwards and lost for good reason. No, BE is logical, but LE is efficient (for machines).

BE is not logical in any way, it is just a tradition, like the use of decimal numbers.

The use of automatic computers has forced a transition from the use of arbitrary conventions that did not have any logical motivation to the most efficient methods of data representation, like binary numbers in little-endian format.

Little-endian is more efficient even when you compute by pen on paper, if it feels awkward that is just because you were taught differently as a child.

There are special circumstances when a big-endian representation is the right choice, e.g. when you interpret a bit string as a binary polynomial, in order to implement an error-detection code with a CRC. However, for general-purpose numbers, little-endian is the optimum choice.

Re: Endian wars and anti-portability: this again?

#56

Post by adrian_b »

pezezin wrote: post #38
chmod775 wrote: post #26

> Big endian systems store numbers the way us humans do: the largest number is written first. Obviously the author was trying to just give a quick example to aid visualization, but here's some nitpicking: I can probably come up with at least IV writing systems used by humans that don't use "big endian" for numbers. Or either, really. Examples: Tally marks, Ancient Egyptian numerals, Hebrew and Attic numerals, and obv…

Roman numerals are big endian though. The current year is written as MMXXVI, not IVXXMM.

The convention that smaller number written to the left of bigger numbers should be subtracted instead of added, is a later addition to the Roman numerals.

The earlier system would write VIIII instead of IX.

With the original Roman numerals, the order of writing was completely irrelevant, because all parts were added and addition is comutative, so VIIII is the same as IIIIV or IIIVI.

Even in the later variant of Roman numerals, you can change the order of many symbols without changing the value.

Re: Endian wars and anti-portability: this again?

#57

Post by adrian_b »

sparkie wrote: post #42

Reminder that the computer's endianness shouldn't matter. You should only care about the endianness of the streams your reading from and writing to. https://commandcenter.blogspot.com/2012/04/byte-order-fallac...

That should have been true, but unfortunately the most popular programming languages do not have distinct data types for bit strings, non-negative numbers, integer residues a.k.a. modular numbers, binary polynomials and binary polynomial residues.

So in C and the like one uses "unsigned" regardless if bit strings or non-negative numbers are needed.

Because no explicit conversions between bit strings and numeric types are used, it is frequent to have expressions where a certain endianness of the numbers is assumed implicitly.

This is the most frequent source of bugs that manifest when a program is run on a machine with an opposite endianness than assumed in the program.

Re: Endian wars and anti-portability: this again?

#58

Post by CJefferson »

burnt-resistor wrote: post #34

I'm glad I did my undergrad at UC Davis in the mid '00s that valued portability and well-defined behavior rather than proprietary or implementation-specific, non-portable assumptions. The lazy, rationalizing throwing out the baby with the bathwater folks are disappointments to engineering excellence.

It's very hard in most language to portably handle endian-ness -- almost by definition, if your code has an issue where endian-ness effects behavior, it's not-portable.

I tend to take another view point (while I understand yours) -- if it's not tested, it doesn't work. And nowadays it's really hard to test big-endian code. I don't have one, I find running different-endian software in QEMU really annoying and difficult.

Re: Endian wars and anti-portability: this again?

#59

Post by an-honest-moose »

zephen wrote: post #23
lowbloodsugar wrote: post #16

Earlier quoted context omitted.

No, BE is intuitive for humans who write digits with the highest power on the left. LE is logical which is also why it is more efficient and more intuitive for humans once they get past “how we write numbers with a pencil”.

> BE is intuitive for humans who write digits with the highest power on the left. But only because when they dump memory, they start with the lowest address, lol. Why don't these people reverse numberlines and cartesian coordinate systems while they're at it?

A lot of graphics APIs do actually reverse the y-coordinate for historical reasons.
Post reply on HN