llvm dev - Jun 2011 - [LLVMdev] Fw: 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

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