llvm dev - Jun 2011 - [LLVMdev] Thinking about "whacky" backends

-------- Original Message --------
Subject: 	Re: [LLVMdev] Thinking about "whacky" backends
Date: 	Fri, 03 Jun 2011 14:44:05 -0400
From: 	Nate Fries <nfries88 at yahoo.com>
To: 	Joachim Durchholz <jo at durchholz.org>



On 6/3/2011 1:38 PM, Joachim Durchholz wrote:
>  Am 01.06.2011 23:25, schrieb Nate Fries:
>>  That said, it seems like it ought to be possible to do the same thing
>>  by emitting bitcode for all supported platform/arch combinations
>  Wait... is bitcode not platform-agnostic?
>  I thought it is.
bitcode is, indeed, platform-agnostic.
However, with any language using a preprocessor (IE, C and C++) or a
similar mechanism of determining the underlying OS and architecture, and
in the case of code using it for such a purpose, LLVM would output
different bitcode. As I said in a previous message, replacing
preprocessor conditionals with runtime ones does not seem like a good
option to me. So this would be the simplest alternative I could think
of. Another option would be meta-data, as I suggested previously as
well.
>>  compressing them in an archive,  then decompressing and either
>>  interpreting or JIT-compiling the appropriate bitcode for the
>>  platform. This would just be a more flexible means to that same end.
>  Not sure how that is more flexible - care to elaborate?
More flexible to the programmer, not to the system. There are many
pieces of code where, to port between Windows, OS X, iOS, Android, and
PC Linux/*BSD/etc would require a ton of preprocessor work.

I'm also considering that perhaps the real best option here would be to
add a new language feature to C++ (ie, invent a new language that is a
strict superset of C++) for a simplistic control flow construct that
only executes code on the specified system and architecture.
__os(WinXP | WinVista | Win7, IA32) { [... 32-bit Windows code here ...] },
__os(WinXP | WinVista | Win7, AMD64) { [... 64-bit Windows code here ...] },
__os(Linux24 | Linux26, IA32) { [...32-bit Linux code here...] },
__os(Linux24 | Linux26, AMD64) { [... 64-bit Linux code here ...] },
__os( , ) { throw new not_supported_exception(); };
Of course that's only a rough idea and will need a ton of refining, but
it should make my point fairly clear.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110603/c0116bd0/attachment.html>

I keep forgetting to CC the list.  Grrr.


----- Forwarded Message -----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Nate Fries <nfries88 at yahoo.com>
> Cc: 
> Sent: Friday, June 3, 2011 2:19 PM
> Subject: Re: [LLVMdev] Thinking about "whacky" backends
> 
> 
> Hello again Nate,
> 
>> ________________________________
>> From: Nate Fries <nfries88 at yahoo.com>
>> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>> Sent: Friday, June 3, 2011 1:44 PM
>> Subject: Re: [LLVMdev] Thinking about "whacky" backends
>> 
>> bitcode is, indeed, platform-agnostic.
>> However, with any language using a preprocessor (IE, C and C++) or a 
>> similar mechanism of determining the underlying OS and architecture,
and
>> in the case of code using it for such a purpose, LLVM would output 
>> different bitcode. As I said in a previous message, replacing 
>> preprocessor conditionals with runtime ones does not seem like a good 
>> option to me. So this would be the simplest alternative I could think 
>> of. Another option would be meta-data, as I suggested previously as
well.
> 
> 
> 
> Why not runtime checks?  The constant folding and dead-code elimination
passes
> would get rid of any redundant code in a later stage of compilation anyway.
 The
> important part, as I see it, is that LLVM already does constant folding and
> dead-code elimination.  Meta-data might require more effort in the long
run.
> 
> --snip--
> 
>> More flexible to the programmer, not to the system. There are many 
>> pieces of code where, to port between Windows, OS X, iOS, Android, and 
>> PC Linux/*BSD/etc would require a ton of preprocessor work. I'm
also
> considering that perhaps the real best option here would be to 
>> add a new language feature to C++ (ie, invent a new language that is a 
>> strict superset of C++) for a simplistic control flow construct that 
>> only executes code on the specified system and architecture.
>> __os(WinXP | WinVista | Win7, IA32) { [... 32-bit Windows code here
...] },
>> __os(WinXP | WinVista | Win7, AMD64) { [... 64-bit Windows code here
...] },
>> __os(Linux24 | Linux26, IA32) { [...32-bit Linux code here...] },
>> __os(Linux24 | Linux26, AMD64) { [... 64-bit Linux code here ...] },
>> __os( , ) { throw new not_supported_exception(); };
>> Of course that's only a rough idea and will need a ton of refining,
but
>> it should make my point fairly clear. 
> 
> 
> There are already many MANY wrappers for OS functionality out there.
 SImply
> choosing some of the more popular ones like wxWidgets, OpenAL Soft and
Irrlicht
> should make the job easier.  The hardest parts would be converting all of
the
> preprocessor macros into the new function one way or the other, whether it
be
> metadata or runtime checks to constant booleans, and converting the
runtimes and
> build environments to use the new wrapper.
> 
> If we're going to make a superset of C++, why not ditch C++ outright
and
> just write a code converter to a friendlier high-level language.  Sorry if 
> I'm not making much headway with you right now but I'm just trying
to
> save work by using existing code wherever possible to save work.
> 
> --Sam
>