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

Ask HN: Is big-endian dead?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 193 posts

Re: Ask HN: Is big-endian dead?

#41

Post by Aloha »

wmf wrote: post #30
valarauca1 wrote: post #26

Big Endian is still supported natively on POWER8/9 Intel added movBE (mov big endian) support in BM2 extension. Networks are still Big Endian. SPARC chips (and now RISC-V) are BIG Endian by default. MIPS just became an independent company a few days ago and they have native Big Endian support. Edit 1: I was wrong about Power8/9 LE/BE

If you use Linux on POWER you're forced to use Big Endian mode as the faster Little Endian mode (according to marketting) is reserved for IBM's operating systems. That's not correct. Ubuntu is LE only and it looks like RHEL is also switching from BE to LE. "The base RISC-V ISA has a little-endian memory system, but non-standard variants can provide a big-endian..." SPARC and MIPS are dead.

MIPS last I looked was quite alive in the embedded space - you're right in that it is effectively dead everywhere else.

Re: Ask HN: Is big-endian dead?

#42

Post by monocasa »

ComputerGuru wrote: post #35
acallan wrote: post #33

Earlier quoted context omitted.

Actually, Silverthorne (the first Atom CPU) added MOVBE.

It seems that Atom has become - ironically - a staging ground for new features that make their way much later to the desktop/mobile x86_64 architecture. Here's another: https://neosmart.net/blog/2017/will-amds-ryzen-finally-bring...

Those little cores get a lot more benefit out of special case instructions.

Re: Ask HN: Is big-endian dead?

#43

Post by BrandoElFollito »

samat wrote: post #37
gumby wrote: post #32

> Little-endian is slightly more confusing for humans... I think you meant to write “Little-endian is slightly more confusing for humans who use left-to-right languages ” as all the R-L languages also put the least significant digit on the right.

Not true. In arabic languages you write text R-L, but numbers are L-R.

Do you mean that you read a text from the right to the left, and when you meet a number you jump to is leftmost digit, then read it LR, then jump agzin to its left (where there is a space) and resume reading text?

Re: Ask HN: Is big-endian dead?

#44

Post by amaccuish »

ufo wrote: post #39
samat wrote: post #37

Earlier quoted context omitted.

Not true. In arabic languages you write text R-L, but numbers are L-R.

Arabic numbers are L-R if you have a big-endian mindset, but R-L if you switch to a little-endian mindset :)

No. Arabic numbers are always L-R...

Re: Ask HN: Is big-endian dead?

#45

Post by ori_b »

BrandoElFollito wrote: post #43
samat wrote: post #37

Earlier quoted context omitted.

Not true. In arabic languages you write text R-L, but numbers are L-R.

Do you mean that you read a text from the right to the left, and when you meet a number you jump to is leftmost digit, then read it LR, then jump agzin to its left (where there is a space) and resume reading text?

Yes.

Re: Ask HN: Is big-endian dead?

#46

Post by kazinator »

The "casting" advantage basically just hides bugs. Because it's often not okay to access just 16 or 8 bits of a 32 bit number; the value is being truncated and that could be a bug.

However, when the number's range is small enough, such code appears to work. Finding the bug is delayed until larger values occur, which is not until its deployed in the field or someone thinks of writing better test cases.

Anyway, if it is okay to truncate, the right thing to do (and ISO C conforming) is to access the underlying type as that type, and then cast the result, not to cast the pointer. I.e. rather than:

    int x = *(int *) ptr64; // breaks on BE; not kosher with ISO C aliasing rules
this:

    int x = (int) *ptr64;  // works on LE and BE
We don't even need the casting operator in the second example. So it's less syntax and clearer code to do the more portable thing.

If we want the bits for that int from some other part of the wider word, we can use shifting and masking.

Re: Ask HN: Is big-endian dead?

#47

Post by kazinator »

ajross wrote: post #8

Little endian is also better for multi-word addition/subtraction. Your first operand will be the low word, which your pointer conveniently already indexes. This was a classic trick in the days of 8 and 16 bit systems, and assembly code for modern modular crypto systems still uses it. Really I think consensus is that the industry focus on big endian systems was actually a mistake. It prioritized programmer comfort in…

OTOH, big-endian is better for comparison; you can tell when one integer is larger than another by looking at as little as just one bit, from the most significant end.

Re: Ask HN: Is big-endian dead?

#48

Post by kazinator »

api wrote: post #3
tlb wrote: post #2

I used to use IETF's network order (big-endian) for everything on disk or over the wire, but I switched to little-endian around 2008. If I ever have to port to a big-endian machine I'll deal with it then. I haven't regretted it yet.

Big-endian is the canonical form for storage and the wire because back when the Internet was designed most "pro" machines were big-endian: Sparc, old MIPS, old PPC, DEC Alpha, etc. All these are dead or dying now. It's easy enough to deal with BE files and protocols by just swapping bytes. I'm referring to hardware architectures. Are there still any big-endian chips out there? Does it still make sense to support big-…

Big-endian means that am ultra-high-speed routing fabric can receive the most significant part of an address address and possibly start making a routing decision before the other bytes of the frame have arrived.

Hands down no brainer.

Even the fact that headers come before payloads is a kind of "big endian", as is the fact that important information tends to occur earlier in headers. Look at a basic Ethernet frame. The destination address is first, so before even knowing the source address, or anything else, the switch can know where that frame will be sent.

Re: Ask HN: Is big-endian dead?

#49

Post by alaaibrahim »

amaccuish wrote: post #44
ufo wrote: post #39

Earlier quoted context omitted.

Arabic numbers are L-R if you have a big-endian mindset, but R-L if you switch to a little-endian mindset :)

No. Arabic numbers are always L-R...

Not exctly accurate, for the part of the number that is Also for the part that is L-R, that is not the rule, as some people still read all the number as R-L (actually in a lot of historical documents that was the case), so the would read 1925 as five and twenty and nine hundred and a thousand. Where is now most people would read it as a thousand, and nine hundred, and five and twenty.

Re: Ask HN: Is big-endian dead?

#50

Post by kazinator »

jfries wrote: post #11

Little-endian is slightly more confusing for humans I've heard this before, but the reason is that you view hex data and list numbers left-to-right as if they were letters. They are not. 0x12345678 stored big-endian, numbering bytes left-to-right: 12 34 56 78 Looks good, but I think that this is actually more confusing, because when you number the bytes and bits you will see that the bytes are written left-to-right,…

When 0x12345678 is stored in little endian, it looks like 78 56 34 12 in a byte dump, which is stupid because hex digits are grouped as pairs and then revered.

The endianness at the bit level is irrelevant because the bits are chunked into bytes, and are usually not even addressable.

A storage format exhibits endianness only when it is addressable.

In the C language, bits are only "addressable" via the shift operators. These are rooted in pure arithmetic, so that 1The only time you deal with "bit endianness" is with certain compressed data formats, and with bitfield layout rules.

Post reply on HN