[LLVMdev] Fw: Thinking about "whacky" backends

[Samuel Crow]

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
>