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

31–40 of 101 posts

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#31

Post by [deleted] »

riscy wrote: post #13
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.

Not only that, but "[target data layout] is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and intro…

[deleted]

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#32

Post by CJefferson »

tomjakubowski wrote: post #30
DannyBee wrote: post #16

Earlier quoted context omitted.

"With software like that, Apple could become independent of any particular software architecture. " Not with the languages they use :) Neither C, nor C++, nor swift, can be made portable to new architectures through bitcode. At least, not without language-level changes to each of them. For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime"…

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc. What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x8…

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#34

Post by tomjakubowski »

CJefferson wrote: post #32
tomjakubowski wrote: post #30

Earlier quoted context omitted.

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc. What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x8…

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

> The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->LLVM stage of compilation.

What is the compile time part of C do you mean? sizeof(T) is evaluated at compile time of course, but it would still produce pseudocode like:

    if (4
Of course, an optimizer would likely constant-fold that conditional expression to remove the branch entirely, but I'm having a difficult time seeing how one could perform different behavior at compile time with sizeof(T) in C.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#35

Post by DannyBee »

CJefferson wrote: post #32
tomjakubowski wrote: post #30

Earlier quoted context omitted.

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc. What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x8…

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

It's worse than this. For example, you'd never be able to issue diagnostics about constexpr's. You'd also not be able to layout structs, etc.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#36

Post by DannyBee »

tomjakubowski wrote: post #30
DannyBee wrote: post #16

Earlier quoted context omitted.

"With software like that, Apple could become independent of any particular software architecture. " Not with the languages they use :) Neither C, nor C++, nor swift, can be made portable to new architectures through bitcode. At least, not without language-level changes to each of them. For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime"…

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc. What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x8…

"Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? "

In LLVM world, Clang is performing most of the ABI lowering.

For C and C++, the answer is "yes", and "it must happen this way", because struct layout/etc will depend on it. Not to mention what you want is at some level, impossible in the LLVM IR. LLVM types are not C/C++ types. This leaves you with no type system capable to do the kind of thing you want to do :)

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#37

Post by bobajeff »

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?

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#38

Post by [deleted] »

tomjakubowski wrote: post #34
CJefferson wrote: post #32

Earlier quoted context omitted.

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

> The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value. I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->…

[deleted]

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#39

Post by DannyBee »

tomjakubowski wrote: post #34
CJefferson wrote: post #32

Earlier quoted context omitted.

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

> The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value. I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->…

#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))

https://scaryreasoner.wordpress.com/2009/02/28/checking-size...

There are many ways to make it perform different behavior at compile time (though admittedly, most are abuse). The above should compile error, but if you push sizeof evaluation, will not.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#40

Post by johnwfinigan »

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…

The book "Inside the AS/400" has some really cool exposition on the unique aspects of the AS/400. If I remember right, the disks and memory are in a single address space, and of course, there is a relational database built in to the operating system.

I have seen the binary translation in action: it was required when POWER6 machines came out. On a POWER5 machine, I remember it taking around 20 minutes for an application that was around 20 MB zipped, but for software licensing reasons not all of the server models exposed the full performance of the processor, so that might not be representative. And at any rate, like the OP said, it's a one time thing, and then the translated version is kept.

Post reply on HN