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

61–70 of 73 posts

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

#61

Post by [deleted] »

Joker_vD wrote: post #46
thinking_cactus wrote: post #36

Earlier quoted context omitted.

My contribution: largest-order-first (big endian) makes sense in real life because people tend to make quick judgements in unreliable situations. For example, take the announcement that you're receiving $132551 dollars. You wouldn't want to hear something like "Hello! You have been awarded one and fifty and five hundred and... and one hundred thousand dollars!", you want to hear "You have been awarded One hundred and…

> My contribution: largest-order-first (big endian) makes sense in real life because people tend to make quick judgements in unreliable situations. For example, take the announcement that you're receiving $132551 dollars. You wouldn't want to hear something like "Hello! You have been awarded one and fifty and five hundred and... and one hundred thousand dollars!", you want to hear "You have been awarded One hundred a…

[deleted]

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

#62

Post by zephen »

userbinator wrote: post #52
zephen wrote: post #28

Earlier quoted context omitted.

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.

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

#63

Post by zephen »

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

Earlier quoted context omitted.

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.

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.

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

#64

Post by zephen »

an-honest-moose wrote: post #59
zephen wrote: post #23

Earlier quoted context omitted.

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

Right. I've done plenty of postscript/PDF.

But 99% of the time the x-coordinate and the number increment from left to right.

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

#65

Post by jaxelr »

ori_b wrote: post #21
josephg wrote: post #3

> If the community is offering you a port to an architecture, whether it is 4 days old or 40 years old, that means the community actively wants to use your software on it – otherwise, nobody would put in the effort. Ports like this are hard, and authors like me already know we are fighting an uphill battle just trying to make upstream projects care. I've had plenty of opensource contributions over the years for some…

> What do I do with those reports? Ignore them? Fix the bugs myself? Bleh. "I don't have access to a test environment, but if you want to write a fix, let me know and I may be able to point you in the right direction" is a perfectly reasonable response.

This, a hundred times. The expectation shouldn't be that you must maintain all scenarios, environments, edge cases.

It's also reasonable to say I simply do not use this software the same way you do. The individual is empowered to fork, contribute and/or collaborate.

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

#66

Post by awilfox »

jltsiren wrote: post #25
nextaccountic wrote: post #17

Earlier quoted context omitted.

Why not wasm?

Wasm is in an awkward place, because Memory64 is widely but not universally supported. Which means that if you want to support Wasm, you probably have to support 32-bit environments in general. Depending on the project, that can be trivial, but it may also require you to rewrite a lot of low-level code in the project and its dependencies.

Ooh, another +1 for reasons to maintain 32-bit support. Thanks for the tip.

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

#67

Post by nextaccountic »

jltsiren wrote: post #25
nextaccountic wrote: post #17

Earlier quoted context omitted.

Why not wasm?

Wasm is in an awkward place, because Memory64 is widely but not universally supported. Which means that if you want to support Wasm, you probably have to support 32-bit environments in general. Depending on the project, that can be trivial, but it may also require you to rewrite a lot of low-level code in the project and its dependencies.

This just means 32 bits is still relevant..

Also: why not riscv?

Anyway, I think that most pain for being low level and portable is due to C and C++, and it's not as painful in Rust. In Rust it's not as common to use non-portable integers like C's int (there is isize/usize but they are used for indexing; logic is supposed to be done in i32/u32/i64/u64), and the Rust stdlib comes with excellent support for dealing with byte orders like https://doc.rust-lang.org/std/primitive.i32.html#method.to_b... (and for more support, usage of https://docs.rs/byteorder/latest/byteorder/ is widespread), among other things

I think it's more immediately clear when Rust code is non portable too. It's not uncommon for random C code to be plagued with undocumented portability issues (and as such, you can't assume that code is portable without some inspection), but unportable Rust code may fail to build on unsupported platforms, which is an excellent idea

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

#68

Post by awilfox »

CJefferson wrote: post #8
nine_k wrote: post #4

Earlier quoted context omitted.

Hmm, if the author of the port cares, why won't the author of the port become a maintainer of that port? This should be a two-way street.

In my experience, as someone who has gone through this as maintainer of two decent sized projects, that simply doesn't work. The author of the 'port' probably doesn't know your whole codebase like you, so they are going to need help to get their code polished and merged. For endian issues, the bugs are often subtle and can occur in strange places (it's hard to grep for 'someone somewhere made an endian assumption'),…

There are many, many users for every one of us packagers. We (at least the four I am aware of, including myself) are not doing 'gotta catch em all', we're doing "we have been notified by users that this package (is not|no longer) working". And it looks like 'gotta catch em all', because there are so many users, still.

There are new users asking how to get Raspberry Pis into aarch64be mode in the Gentoo Arm project channels. There are thousands and thousands of Power Macs. SPARC servers with ridiculous amounts of cores and computer power are super cheap on eBay because Oracle ended support for them - and this is a great way to get a huge thread count cheap, if your software actually runs on it.

Make the BE CI optional if you need to. That way, the maintainer has time to find and fix it, and you can still merge other changes while it runs. What binutils did was have the BE CI run separately and specifically ping the BE maintainers - that way, they know the build's failing, and no one else is bothered with it.

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

#69

Post by yjftsjthsd-h »

zephen wrote: post #63
yjftsjthsd-h wrote: post #39

Earlier quoted context omitted.

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?

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

#70

Post by zephen »

yjftsjthsd-h wrote: post #69
zephen wrote: post #63

Earlier quoted context omitted.

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.

Post reply on HN