Apple’s Bitcode Telegraphs Future CPU Plans • Hacker News Board

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#51

Post by ahomescu1 » Wed, Jun 17, 2015, 1:41 AM UTC

bobajeff wrote: post #37

monocasa wrote: post #2

I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is. There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.

Perhaps someone can explain to me why converting a binary straight from one architecture to another couldnt be done. If emulators can work why not translaters?

The problem is that perfect disassembly (figuring out where every instruction starts, and if bytes are instructions or data) of an arbitrary program is undecidable. Emulators get around that problem by only disassembling instructions that actually get executed at run-time (and therefore can safely be called "code").

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#52

Post by hyperpape » Wed, Jun 17, 2015, 1:58 AM UTC

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

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

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#53

Post by nickpsecurity » Wed, Jun 17, 2015, 2:04 AM UTC

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 over and over for decades. Always one to keep in mind.

Going further, I think a team could get interesting results combining this with design-by-contract, typed assembly, and certified compilation. Much like verification condition generators, the compilation process would keep a set of conditions that should be true regardless of what form the code is in. By the time it gets to the lower level, those conditions & the data types can be used in the final compile to real architecture. It would preserve a context for doing safe/secure optimizations, transforms, and integration without the original source.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#54

Post by ahomescu1 » Wed, Jun 17, 2015, 2:04 AM UTC

hyperpape wrote: post #52

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

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

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#55

Post by nickpsecurity » Wed, Jun 17, 2015, 2:11 AM UTC

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…

I always thought it was just one of those arbitrary choices made by companies with massive headaches resulting. I never thought to ask anyone if there was a good reason for one or the other. You've made quite the case for big-endian. I'm saving your comment (with attribution) for the next time this comes up in discussion. ;)

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#56

Post by nickpsecurity » Wed, Jun 17, 2015, 2:15 AM UTC

DannyBee wrote: post #18

monocasa wrote: post #2

I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is. There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.

You are correct, and the article isn't even close to right. There are things you can do if the ABI's are the same, such as optimize for microarches, but they otherwise have literally no idea what they are talking about. Bitcode is meant for repeated optimization of the same IR. That is, it would make sense to start from a well-optimized AOT compiled version of bitcode, then JIT the bitcode at runtime and try to come…

I appreciate the clarification.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#57

Post by nickpsecurity » Wed, Jun 17, 2015, 2:17 AM UTC

spitfire wrote: post #6

stcredzero wrote: post #4

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…

Sounds somewhat similar to the IBM AS/400 (renamed many times). Applications were shipped as byte code and translated to the local machine architecture. The translated byte code was appended to the application, a but like NeXT fat binaries or OS-X's universal binaries. The native byte code was 64bit, though iirc the first implementation used a 32bit address. The result was you could ship an application once and when…

We were thinking on the same lines. IBM System/38 was truly a brilliant, integrated design in so many ways. Even had capability-security built into the hardware. Check it out at the reference below. Intel made a monster of a system too. Would love to have either on a SOC or an inexpensive server.

http://homes.cs.washington.edu/~levy/capabook/index.html

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#58

Post by mschulze » Wed, Jun 17, 2015, 2:18 AM UTC

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

German speaker here, that's correct. When the number is between 1000-1999 the "one" in "one thousand" is sometimes omitted, so "thousand two and forty".

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#59

Post by nickpsecurity » Wed, Jun 17, 2015, 2:19 AM UTC

RayDonnelly wrote: post #19

exelius wrote: 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…

In my industry, app data size swamps app executable size by a factor of about 2000.. So all this app thinning stuff seems useless (to me).

Well-optimized, lean apps often use cache and registers more efficiently. This brings performance boosts. That can save real $$$ on hardware or just let you do more with it.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#60

Post by kylebgorman » Wed, Jun 17, 2015, 2:27 AM UTC

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

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