Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


So, to be clear, I was writing about when you design a computer. It truly is the same number of gates either way. I have written my fair share of verilog. At one level, it's just a convention.

For the use of a computer, yes, if you are doing multi-word arithmetic, it can matter.

OTOH, to be perfectly fair and balanced, multi-word comparisons work better in big-endian.


Not only dumping, but yes I agree it only matters when humans are in the loop. My most annoying encounters with endianness was when writing and debugging assembly, and I assure you dumping memory was not the only pain point.


I've done plenty of assembly language. It was the bulk of my career for over 20 years, and little endian was just fine, and big endian was not.


I can easily imagine someone getting used to LE, but how is BE not fine as a human writing asm?


If you're mapping datatypes, or dealing with bit arrays.

The root of the problem, which manifests itself in scenarios far more often than you might think, is that in big endian, the location corresponding to 2**n within an integer maps to byte X - n/8 - 1, where X is the number of bytes in the mapped-to data structure, and if it's true big-endian like some IBM processors, the bit maps to bit number 7 - (n%8), but with most processors which are mixed endian, such as the M68K, it's merely n%8.

With little endian, the byte location is n/8 and the bit location is n%8.

A trite example of when this occurs is that you have a description of bit numbers within 4-byte hardware registers and you want to develop an integer mask for those.


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


My comment was in response to the parent's

> FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it

I should have fleshed it out more fully, but basically, it was about how when you design an ALU, it's literally the same number of gates whether you swap the pins when you connect it to the rest of the system or not.

Using the computer is, of course, a different story that depends a lot on design decisions made when implementing it, and depending on your usage, endianness can matter more.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: