similar to: [LLVMdev] Building a stable bitcode format for PNaCl - based on LLVM IR

> The document is available as a PDF here: > https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo0OWYwZjVkYWFjOWNjODE1 > > And in text here: > https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/stability-of-the-pnacl-bitcode-abi First, sorry for jumping in an old thread. I had this marked but had not been able to read it

Hello, Following an earlier email ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html), we've published an initial version of the PNaCl bitcode reference manual online - http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl bitcode is a restricted subset of LLVM IR. The reference manual is quite terse, so for the bigger picture I'll repost links to the design

Is it possible to use PNaCl infrastructure (i.e. translation and execution in a sandbox) without a Chrome ? I mean a something like a standalone VM like Java or Mono/C#. Dmitri Am 18.06.2013 17:22, schrieb Eli Bendersky: > Hello, > > [The first paragraph is safe to skip if you already know what PNaCl is.] > The Portable Native Client (PNaCl) project is a toolchain for producing

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

On 1 August 2013 00:11, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > we've published an initial version of the PNaCl bitcode reference > > manual online - > > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > > bitcode is a restricted subset of LLVM IR. > > > > Any comments would be

On 18 June 2013 15:27, Dmitri Rubinstein <dmitri.rubinstein at googlemail.com>wrote: > Is it possible to use PNaCl infrastructure (i.e. translation and execution > in a sandbox) without a Chrome ? > > I mean a something like a standalone VM like Java or Mono/C#. > Yes. The NaCl tool 'sel_ldr' will run a program inside a sandbox outside of the web browser. We do a

From the provided documentation I understood that in memory data structures of a PNaCl program are incompatible to the host program because ABIs are different (e.g. PNaCl pointers are always 32-bit even when running on x86_64 platform). So PNaCl program can't access any data structures of the host program directly. The only communication way is by using syscalls, but the document does not

On 2013-07-30 22:11, Eli Bendersky wrote: > we've published an initial version of the PNaCl bitcode reference > manual online - > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > bitcode is a restricted subset of LLVM IR. > > Any comments would be most welcome. Hi Eli, I appreciate you for opening the process for input and comments. One question stood

Hi Mark, On 2013-08-02 04:11, Mark Seaborn wrote: > That note in the documentation seems to be incorrect, because LLVM > will do tail call optimisations on at least x86 when using the "ccc" > calling convention. For example: > > $ cat tail_call1.c > void foo(int arg); > void bar(int arg) { > foo(arg); > } > > $ clang tail_call1.c -S -o - -O2 >

On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: > Instead of a blacklist, why not a whitelist? Given the size of LangRef, > you're bound to leave something out of your blacklist that needs to be > there (also, future additions to LLVM IR will need to be added to the > blacklist; are you sure you can catch *all* of them?). A whitelist seems >

On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > > > > On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: > >> Instead of a blacklist, why not a whitelist? Given the size of LangRef, >> you're bound to leave something out of your blacklist that needs to be >> there (also, future additions to

Instead of a blacklist, why not a whitelist? Given the size of LangRef, you're bound to leave something out of your blacklist that needs to be there (also, future additions to LLVM IR will need to be added to the blacklist; are you sure you can catch *all* of them?). A whitelist seems much less prone to breakage or unexpected behavior. -- Sean Silva -------------- next part -------------- An

I'm not familiar with PNaCl but, FWIW, I'd say the three main advancements the CLR made over the JVM are: . Structs (aka value types). . Reified generics. http://research.microsoft.com/pubs/64031/designandimplementationofgenerics.p df . Tail call elimination. http://research.microsoft.com/pubs/69132/babel01.pdf Structs give you more freedom around memory

On Wed, Jul 31, 2013 at 11:55 PM, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > we've published an initial version of the PNaCl bitcode reference > > manual online - > > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > > bitcode is a restricted subset of LLVM IR. > > > > Any comments

On 18 June 2013 15:08, Sean Silva <silvas at purdue.edu> wrote: > On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > >> On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: >> >>> Instead of a blacklist, why not a whitelist? Given the size of LangRef, >>> you're bound to leave something out

We (PNaCl team) are in the process of removing older documentation, this is probably more accurate: https://developers.google.com/native-client/dev/ On Tue, Dec 17, 2013 at 6:50 AM, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Check out PNaCL > http://www.chromium.org/nativeclient/pnacl > > Cheers, > Sam > > Sam Parker > Research Student > Electronic Systems

On Tue, Jun 18, 2013 at 3:08 PM, Sean Silva <silvas at purdue.edu> wrote: > > > > On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > >> >> >> >> On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: >> >>> Instead of a blacklist, why not a whitelist? Given the size of LangRef,

Thanks, I hadn't heard about PNaCl, it's very interesting. I'm currently swimming in http://llvm.org/docs/ trying to learn more about LLVM-IR... Selon JF Bastien <jfb at google.com>: > We (PNaCl team) are in the process of removing older documentation, > this is probably more accurate: > https://developers.google.com/native-client/dev/ > > On Tue, Dec 17,