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
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 >
What benefit do you get from having a backend here rather than an interpreter for LLVM IR? Cameron On May 31, 2011, at 5:30 PM, Joachim Durchholz wrote:> 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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/ -Henry
Am 01.06.2011 04:57, schrieb Cameron Zwarich:> What benefit do you get from having a backend here rather than an interpreter for LLVM IR?A backend that's self-sufficient and covers the entire Unixoid world. That cuts down on the number of binaries that one needs to provide for autoinstallers and such. Generated Perl could be used to bootstrap an LLVM IR interpreter, for example. Regards, Jo
On Wed, Jun 1, 2011 at 2:30 AM, Joachim Durchholz wrote:> 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?Have you looked at Emscripten? (https://github.com/kripken/emscripten) "Emscripten is an LLVM-to-JavaScript compiler. It takes LLVM bitcode - which can be generated from C/C++, using llvm-gcc or clang, or any other language that can be converted into LLVM - and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run)." You may be able to estimate the amount of work needed based on the development effort required by Emscripten. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds