[LLVMdev] Fw: Thinking about "whacky" backends

Samuel Crow samuraileumas at yahoo.com
Wed Jun 1 10:00:40 PDT 2011





----- Original Message -----
> From: Henry Mason <thefridgeowl at gmail.com>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Wednesday, June 1, 2011 11:53 AM
> Subject: Re: [LLVMdev] Fw:  Thinking about "whacky" backends
> 
> 
> On May 31, 2011, at 7:36 PM, Samuel Crow wrote:
> <snip>
>>> 
>>>  Now my idea for a whacky backend:  Just a wrapper of the bitcode writer 
> with its 
>>>  own special target triple:  bitcode-tarrget-neutral and a generic data 
> layout 
>>>  that aligns to single bytes as a placeholder only.  It should disallow 
>>>  overriding the alignment of individual instructions to avoid illegal 
> settings 
>>>  for the data layout.  When compiling it with LLC, it should require 
> that the 
>>>  target triple and data layout be overridden by a real processor and 
> OS.  This 
>>>  would allow LLVM to actually function as a statically compiled virtual 
> machine 
>>>  when used in conjunction with my wrapper of the LibC runtimes.  Of 
> course the 
>>>  wrapper code would allow special inlining as it would be the only 
> interface to 
>>>  the underlying OS.
>>> 
>>>  What do you think of my whacky backend idea?
> 
> This is pretty much what's happening with Portable Native Client, right?
> 
> http://www.chromium.org/nativeclient/pnacl
> 
> See also the first presentation from the November LLVM meeting: 
> http://llvm.org/devmtg/2010-11/
> 

Hello Henry,

Yes, it is slowly happening there too.  But their double-sandbox on the browser method vs. my simple wrapper method makes things a bit different.  I don't work for Google and I'd like to see browsers take a less prominent role.  I've seen the video and, in interest, I joined the NaCl mailing list.  Almost nothing is happening with the PNaCl end of things on the NaCl mailing list.  I'm either on the wrong list or else they're keeping things hush hush.

--Sam




More information about the llvm-dev mailing list