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

The Byte Order Fiasco

justine.lol

Post reply on HN
Print view View original

31–40 of 378 posts

Re: The Byte Order Fiasco

#31

Post by bonzini »

bregma wrote: post #7
amelius wrote: post #3

Byte order is one of the great unnecessary historical fuck ups in computing. A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM. Sigh!

And which is the correct byte ordering, pray tell?

Little endian has the advantage that you can read the low bits of data without having to adjust the address. So you can for example do long addition in memory order rather than having to go backwards, or (with an appropriate representation such as ULEB128) in one pass without knowing the size.

Re: The Byte Order Fiasco

#32

Post by raverbashing »

genmon wrote: post #26
londons_explore wrote: post #15

Remember how we used to have machines with a 7 bit byte? And everything was written to handle either 6, 7, or 8 bit bytes? And now we've settled on all machines being 8 bit bytes, and programmers no longer have to worry about such details? Is it time to do the same for big endian machines? Is it time to accept that all machines that matter are little endian, and the extra effort keeping everything portable to big end…

That reminds me of a project to interface with vending machines. (We built a bookshop in a vending machine that would tweet whenever it sold an item, with automated stock management.) Vending machines have an internal protocol a little like I2C. We created a custom peripheral to bridge the machine to the web, based on a Raspberry Pi. The protocol was defined by Coca Cola Japan in 1975 (in order to have optionality in…

Well you could bit bang and the 9 bits wouldn't be an issue. (Even if you had a tiny PIC microcontroler just to do that)

This is best solvable the closer to the device in question and in the simplest way possible.

Re: The Byte Order Fiasco

#33

Post by chrisseaton »

rwmj wrote: post #8

If you can assume GCC or Clang then __builtin_bswap{16,32,64} functions are provided which will be considerably more efficient, less error-prone, and easier to use than anything you can homebrew.

__builtin_bswap does exactly the same thing as the macros.

Re: The Byte Order Fiasco

#35

Post by cygx »

> So the solution is simple right? Let's just use unsigned char instead. Sadly no. Because unsigned char in C expressions gets type promoted to the signed type int.

If you do use unsigned char, an alternative to masking would be performing the cast to uint32_t before instead of after the shift.

edit: For reference, this is what it would look like when implemented as a function instead of a macro:

    static inline uint32_t read32be(const uint8_t *p)
    {
        return (uint32_t)p[0]

Re: The Byte Order Fiasco

#36

Post by BlueTemplar »

genmon wrote: post #26
londons_explore wrote: post #15

Remember how we used to have machines with a 7 bit byte? And everything was written to handle either 6, 7, or 8 bit bytes? And now we've settled on all machines being 8 bit bytes, and programmers no longer have to worry about such details? Is it time to do the same for big endian machines? Is it time to accept that all machines that matter are little endian, and the extra effort keeping everything portable to big end…

That reminds me of a project to interface with vending machines. (We built a bookshop in a vending machine that would tweet whenever it sold an item, with automated stock management.) Vending machines have an internal protocol a little like I2C. We created a custom peripheral to bridge the machine to the web, based on a Raspberry Pi. The protocol was defined by Coca Cola Japan in 1975 (in order to have optionality in…

We really should have moved to 32 bit bytes when moving to 64 bit words. Would have simplified Unicode considerably.

Re: The Byte Order Fiasco

#37

Post by erk__ »

pantalaimon wrote: post #9
amelius wrote: post #3

Byte order is one of the great unnecessary historical fuck ups in computing. A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM. Sigh!

The good thing is that Big Endian is pretty much irrelevant these days. Of all the historically Big Endian architectures, s390x is indeed the only one left that has not switched to little endian.

As there was talk about in a subthread yesterday [0] so does arm support big endian though it is not used as much anymore is it still there.

POWER also still uses big endian though recently little endian POWER have gotten more popular

[0]: https://news.ycombinator.com/item?id=27075419

Re: The Byte Order Fiasco

#38

Post by rwmj »

jart wrote: post #19
rwmj wrote: post #8

If you can assume GCC or Clang then __builtin_bswap{16,32,64} functions are provided which will be considerably more efficient, less error-prone, and easier to use than anything you can homebrew.

That's not true. If you write the byte swap in ANSI C using the gigantic mask+shift expression it'll optimize down to the bswap instruction under both GCC and Clang, as the blog post points out.

Assuming the macros or your giant expression are correct. But you might as well use the compiler intrinsics which you know are both correct and the most efficient possible, and get on with your life.

Re: The Byte Order Fiasco

#39

Post by js8 »

bonzini wrote: post #31
bregma wrote: post #7

Earlier quoted context omitted.

And which is the correct byte ordering, pray tell?

Little endian has the advantage that you can read the low bits of data without having to adjust the address. So you can for example do long addition in memory order rather than having to go backwards, or (with an appropriate representation such as ULEB128) in one pass without knowing the size.

Maybe I am biased working on mainframes, but I would personally take big endian over little endian. The reason is when reading a hex dump, I can easily read the binary integers from left to right.
Post reply on HN