Live data from Hacker News

Apple’s Bitcode Telegraphs Future CPU Plans

medium.com

91–100 of 101 posts

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#91

Earlier quoted context omitted.

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 man…

Unlikely. Cardinal numbers in Old English, long before the slightest chance of contact with Arabs, were virtually identical to the modern system with respect to order of terms.

"For a similar situation in language, think of accents and the many different ways you can pronounce the same word."

Could you be more specific as to what you mean?

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#92
post #9

Earlier quoted context omitted.

You mean just like Java? The performance overhead of Java versus native code is pretty negligible at this point, and Swift is pretty similar to Java 8. I suspect if Apple wanted to go the intermediate compilation route, they would have just used Java. I suspect Bitcode is more about helping developers ship a single binary that works across 7 or 8 devices with slightly different ISAs. App thinning is a big push for Ap…

Every single binary every emitted by LLVM has been Bitcode during the compilation process. The only new element here is that Apple's asking for this intermediate product in order to be on the App Store.

Yep, and what I'm saying is that Bitcode doesn't help portability; only in producing device-optimized binaries for variants of the same ISA. The end goal here is reducing app size, not making it easier to port things to a new ISA. A new ISA wouldn't be impossible -- Apple is one of the few companies to successfully navigate this transition -- but IMO Apple would be better served on the Mac side by lower-power x86 parts (which are finally available) than higher-performing ARM CPUs.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#93

With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms. With software like that, Apple could become independent of any particular software architectu…

TAOS, what a blast from the past. That system was cool. Sad that it never came to be.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#94

This is a smart move. It's essentially what the System/38 (later AS/400 & IBM i) did. They had an ISA or microcode layer that all apps were compiled to. Then, that was compiled onto whatever hardware they ran on. When IBM switched to POWER processors, the just modified that low layer to compile to POWER processors. That let them run the old apps without recompilation of their original source. They used this strategy…

Based on other comments here, it sounds like the LLVM Bitcode representation is more closely tied to a specific architecture than the System/38 intermediate representation was. Same idea, though.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#95
post #63

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…

See https://en.wikipedia.org/wiki/P-adic_number for an overview of the system of numbers that actually works this way, similar to https://en.wikipedia.org/wiki/Two's_complement with infinitely long registers.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#96

This is a smart move. It's essentially what the System/38 (later AS/400 & IBM i) did. They had an ISA or microcode layer that all apps were compiled to. Then, that was compiled onto whatever hardware they ran on. When IBM switched to POWER processors, the just modified that low layer to compile to POWER processors. That let them run the old apps without recompilation of their original source. They used this strategy…

Based on other comments here, it sounds like the LLVM Bitcode representation is more closely tied to a specific architecture than the System/38 intermediate representation was. Same idea, though.

I agree. That's either an advantage or another opportunity for modern IT to learn from the past. Those old systems were full of so many tricks they're still outclassing modern efforts in some ways haha.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#97

Earlier quoted context omitted.

As a British English speaker, I'd say "yes". Technically, I'd drop the "th of" and just say/write "11 September 2001".

Interesting. Would you choose "three July twenty fifteen", "July third twenty fifteen", or "the third of July twenty fifteen" (substitute "two thousand" for "twenty" if you like)? Assume someone has asked you the date and you're responding out loud.

I would say "three July twenty fifteen".

It took me a while to figure this out because actually it's quite rare to speak a date including a year without reading it - most spontaneously-spoken dates are this year (so the year is implied) and for a read dates, I'd probably say whatever was written.

The clincher was how I'd say my birth date, which would be of the form above.

I'm not claiming to be the definitive British English speaker, though! ;)

...and as another poster commented, it might depend on context - for example, "September 11" is often used in British English because it refers to an American event.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#98

Earlier quoted context omitted.

Interesting. Would you choose "three July twenty fifteen", "July third twenty fifteen", or "the third of July twenty fifteen" (substitute "two thousand" for "twenty" if you like)? Assume someone has asked you the date and you're responding out loud.

I would say "three July twenty fifteen". It took me a while to figure this out because actually it's quite rare to speak a date including a year without reading it - most spontaneously-spoken dates are this year (so the year is implied) and for a read dates, I'd probably say whatever was written. The clincher was how I'd say my birth date, which would be of the form above. I'm not claiming to be the definitive Britis…

As a Brit, IMO both are perfectly acceptable in English prose. It isn't unusual to say "October the 4th" as opposed to "the 4th of October".

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#99
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".

Yeah, but the way individual languages do numbers doesn't necessarily make sense. In French, 99 is read as "four-twenties and ten-plus-nine"

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#100

Earlier quoted context omitted.

> 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 man…

Unlikely. Cardinal numbers in Old English, long before the slightest chance of contact with Arabs, were virtually identical to the modern system with respect to order of terms. "For a similar situation in language, think of accents and the many different ways you can pronounce the same word." Could you be more specific as to what you mean?

I mean the writing is identical, but the pronounciation varies wildly.
Post reply on HN