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

Apple’s Bitcode Telegraphs Future CPU Plans

medium.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#61

Post by sunfish »

drfuchs wrote: post #45
kmicklas wrote: post #28

Earlier quoted context omitted.

Why on earth would you ever want to _return_ to big-endian?

Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). B…

Humans never chose to communicate via hex dumps either. We're making some concessions to hardware concerns here at the cost of human readability anyway, so one can debate whether endianness should also be considered that way. Protocol decoders are really great.

Little endian is more natural for data structures. The least significant bit goes in the byte with the least address, and the most significant bit goes in the byte with the greatest address, so you never have to remember which way you're going, which is particularly nice when working with bitvectors and bit fields.

"Left" and "right" can go either way, depending on which kind of diagram you draw, even on big-endian machines, so those words always end up ambiguous. Stick to bit significance and address order and everything is unambiguous and naturally inclined to little endian.

I'm not sure what you mean by the bit shifting case. The 8 char ASCII sting compare is a neat trick with limited applicability these days.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#62

Post by DavidSJ »

ahomescu1 wrote: post #54
hyperpape wrote: post #52

Earlier quoted context omitted.

Do they also call 1042 "Forty two and one thousand"?

After looking up some German for beginners (German speakers, feel free to correct me), I found out that 1042 is read like "one thousand two and forty".

Also known as middle endian.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#63

Post by wz1000 »

ahomescu1 wrote: post #50
drfuchs wrote: post #45

Earlier quoted context omitted.

Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). B…

> Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Actually, it is possible that that was nothing more than an accident. We use Arabic numerals, and Arabic languages are written right-to-left. Then there are languages like German where digits are read in reverse, so "42" is read as "two-and-forty".

I think the way we do it is more natural. Numbers which have an infinite decimal expansion towards the right side of the decimal point are relatively much more common and useful compared to numbers which have an infinite decimal expansion towards the left.

For example, you can write out e as 2.7182...

However, if we were to flip this notation, ...2817.2, it isn't clear where to begin writing the number, if we read(and write) from left to write. With the regular representation, you write out the 'major' parts of the number first and then give out as many details as you want. You have the beginning of your string in mind. With a reversed system, you don't have the beginning but the end of the string in mind.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#64

Post by mitchty »

DavidSJ wrote: post #62
ahomescu1 wrote: post #54

Earlier quoted context omitted.

After looking up some German for beginners (German speakers, feel free to correct me), I found out that 1042 is read like "one thousand two and forty".

Also known as middle endian.

Even if its weird, its nothing like French numerals.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#65

Post by ahomescu1 »

kylebgorman wrote: post #60
ahomescu1 wrote: post #50

Earlier quoted context omitted.

> Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Actually, it is possible that that was nothing more than an accident. We use Arabic numerals, and Arabic languages are written right-to-left. Then there are languages like German where digits are read in reverse, so "42" is read as "two-and-forty".

The German "decade flip" is restricted to the tens and unit places; otherwise the order is English-like, with larger terms leading. The cardinal number systems for most major languages lead with larger terms (as in English). I don't think there's anything deep about this, it's probably an accident. And there are languages which lead with smaller terms, such as Malagasy (the national language of Madagascar). The order…

> The ordering of digits in Arabic is not obviously relevant, per se, since spoken English ("one hundred twenty one") matches the order of the Arabic numbers, too.

I think it is relevant. It is possible that Western mathematics copied the Arabic notation (with right-to-left numbers), without also copying the correct way to read it (also right-to-left). For a similar situation in language, think of accents and the many different ways you can pronounce the same word.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#67

Post by Retra »

wz1000 wrote: post #63
ahomescu1 wrote: post #50

Earlier quoted context omitted.

> Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Actually, it is possible that that was nothing more than an accident. We use Arabic numerals, and Arabic languages are written right-to-left. Then there are languages like German where digits are read in reverse, so "42" is read as "two-and-forty".

I think the way we do it is more natural. Numbers which have an infinite decimal expansion towards the right side of the decimal point are relatively much more common and useful compared to numbers which have an infinite decimal expansion towards the left. For example, you can write out e as 2.7182... However, if we were to flip this notation, ...2817.2, it isn't clear where to begin writing the number, if we read(an…

All you are pointing out is that mixing little-endian and big-endian may cause trouble. You're not saying anything about which of the two is better.

Anyway, it doesn't matter what you think is 'more natural.' Computing in binary probably feels less natural to you, but nobody is going to stop making binary computers because of that.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#68

Post by pilif »

I really hope this bitcode feature isn't going to cause a lot of trouble for app developers. Up until now, the app you built on your machine (and tested on your devices) is the app you submitted and which is running on your customers machines.

In the future, when your app crashes on customer's machines and doesn't on yours, how are you going to debug much less explain this to apple and have them fix the issue for you?

This is especially scary when you consider the turnaround time of ~2 weeks before your new build becomes available in the app store for you to test.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#69

Post by lilendian4lyfe »

drfuchs wrote: post #45
kmicklas wrote: post #28

Earlier quoted context omitted.

Why on earth would you ever want to _return_ to big-endian?

Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). B…

Well for starters, ARM has runtime-selectable endianness, so if Apple had felt any reason to do so, they would have used a big-endian ABI by now.

This article covers the practical tradeoffs of little and big-endianness well: https://fgiesen.wordpress.com/2014/10/25/little-endian-vs-bi...

The tl;dr is that little-endian was a smart performance optimization in the early microprocessor days when nearly all arithmetic was effectively bignum arithmetic (because the ALUs were only 4 or 8 bits wide), but that doesn't really matter now, so we're stuck with little-endian despite big-endian having some small developer productivity benefits.

The thing is, little-endian won pretty much everywhere outside of network protocols, so almost all of the common data formats store words in little-endian format as a performance optimization. By going big-endian, you'd be both forced to eat a byte-swapping performance hit on every load or store to these formats, and you'd break a tremendous amount of software that assumes it is running on a little-endian architecture. Dealing with those headaches would absolutely not be worth the trouble for the almost insignificant benefit of slightly easier to read hex dumps, or the slightly more useful benefit of string comparison via memcmp that could be better performed by dedicated SIMD instructions anyway.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#70

Post by daemin »

drfuchs wrote: post #45
kmicklas wrote: post #28

Earlier quoted context omitted.

Why on earth would you ever want to _return_ to big-endian?

Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). B…

Little endian is easier to deal with at the machine level as you don't need to adjust pointer offsets when referencing a smaller sized variable. A pointer to an 8, 16, 32, 64, 128 bit quantity will be the same. Big endian you will need to adjust the pointer up/down accordingly.
Post reply on HN