Hacker News Reader

Comment by tluyben2 | Hacker News Reader

It says 'LLVM style intermediate code'; why not actual LLVM intermediate code? What would be the reason for an alternative? If it would be actual LLVM code it would be easier to compile from programming languages and to different backends, right?

View on HN

It is based on LLVM, but presumably they have to modify it for their particular needs. The PNaCl bitcode reference manual goes into more detail: https://developers.google.com/native-client/dev/reference/pn...

More details on the design process are available here: http://www.chromium.org/nativeclient/pnacl/stability-of-the-... (there's a link to a nicely formatted PDF in the bottom).

TL;DR: a lot of thought went into it :)

"The PNaCl bitcode is a restricted subset of LLVM IR."

https://groups.google.com/forum/#!msg/llvm-dev/lk6dZzwW0ls/J...

LLVM bitcode is quite large and not really suited to being a transport format. The bytecode they did come up with is probably a LLVM frontend.

Any reference to support your claim that LLVM bit code is quite large ?

It's quite obvious if you look at the spec. It retains very large amounts of information that is simply not needed merely for executing programs, but is quite useful for compiler backends and tools.

It's quite smart to write a LLVM backend and frontend for a custom (compact) bytecode.

"Finalized" and gzipped PNaCl code is about the same size as gzipped x86 or gzipped emscripten-generated JS code. PNaCl code seems to have a static overhead of about 400kByte, probably statically linked code which is either handled through Web APIs in emscripten, or dynamically linked CRT in native executables.

Reply on news.ycombinator.com