Google Introduces Portable Native Client

Re:Google Introduces Portable Native Client by pjin on Saturday May 18, 2013 @02:06AM (#5728063)

To me, the most interesting thing about PNaCl is that it'll be the first real test of LLVM as a portable assembly bitcode, rather than just a compiler IR. There are arguments for why LLVM may not be such a good idea, but given the momentum it's been making, I can only see good things happening for LLVM if more people use it.

[ Parent | on HN ]

Re:Google Introduces Portable Native Client by millstone on Saturday May 18, 2013 @03:42AM (#5728197)

Right. I had always thought that LLVM bitcode was unsuitable as a portable representation because it inevitably encoded architecture-specific details.

Consider code like this:

    int lsize(void) { return sizeof(void *); }

how would this be compiled portably, so that it returns 4 or 8 as appropriate? What would the LLVM bitcode look like?

[ Parent | on HN ]

Re:Google Introduces Portable Native Client by jensnockert on Saturday May 18, 2013 @03:50AM (#5728207)

This is true for LLVM bitcode in general, but PNaCl specifies an abstract machine that defines pointers as 4 bytes long. It also specifies Little Endian &c.

See http://www.chromium.org/nativeclient/pnacl/bitcode-abi#TOC-D...

[ Parent | on HN ]

Re:Google Introduces Portable Native Client by kryps on Saturday May 18, 2013 @02:15AM (#5728073)

The second real test. Android Renderscript uses LLVM for portable bytecode already.

[ Parent | on HN ]

Re:Google Introduces Portable Native Client by dietrichepp on Saturday May 18, 2013 @03:27AM (#5728168)

Actually, emscripten does the same thing: LLVM->JS.

[ Parent | on HN ]