Sorry, forgot to CC the list. ----- Forwarded Message -----> From: Samuel Crow <samuraileumas at yahoo.com> > To: Joachim Durchholz <jo at durchholz.org> > Cc: > Sent: Tuesday, May 31, 2011 9:35 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Hello, > > > ----- Original Message ----- >> From: Joachim Durchholz <jo at durchholz.org> >> To: llvmdev at cs.uiuc.edu >> Cc: >> Sent: Tuesday, May 31, 2011 7:30 PM >> Subject: [LLVMdev] Thinking about "whacky" backends >> >> I've been tossing around some ideas about high-level backends. >> >> Say, have LLVM emit Perl code. >> >> Sounds whacky but isn't. It's good for the first bootstrapping > phase in >> environments where you don't have a C compiler, where you don't > have a >> cross-compiled binary for download, but you can execute Perl. >> It also makes a great inspect-the-sources-with-an-editor stage for >> aspiring compiler writers. >> >> Or emit JVM bytecode, or maybe for the upcoming Parrot VM that the Perl >> community is building. >> >> The questions I'm having is: >> 1. Is this really a useful approach? >> 2. How much work would such a backend be? >> >> Regards, >> Jo > > > 1. Not terribly. You probably wouldn't even be able to use the TableGen > utility to ease the pain of writing such a backend. > > 2. A lot. Just look at the instruction set of the Intermediate representation > and imagine trying to map it to a high-level language. > > 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? > > --Sam >
----- 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
On Wed, Jun 1, 2011 at 12:53 PM, Henry Mason <thefridgeowl at gmail.com> wrote:> 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/PNaCl fixes data layout to be just "portable enough" to cover x86, ARM, and x86_64, IIUC. The size of a pointer in PNaCl is always 32 bits, for example. It would still be useful to be able to generate target neutral bitcode that doesn't need a special runtime and can interface with regular native libraries. We've talked about this before, but just thinking about it a bit further, here are some examples of features people have asked for to help make their frontends more target-neutral: - a pointer-sized integer type - unions - bitfields My understanding is that these are rejected because the primary consumers of the IR are the optimizers and the code generators. They don't want to have to deal with these extra features complicating the IR. They prefer to see bitcasts and logical operators over unions and bitfields. An alternative is to introduce these features, but add a target lowering phase that strips them from the IR and replaces them with the target-dependent equivalent. The downside here is that it undermines the "single IR" LLVM approach. OTOH, it's a lot like running mem2reg before doing optimizations. Reid