<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <br>
    <br>
    -------- Original Message --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th valign="BASELINE" align="RIGHT" nowrap="nowrap">Subject: </th>
          <td>Re: [LLVMdev] Thinking about "whacky" backends</td>
        </tr>
        <tr>
          <th valign="BASELINE" align="RIGHT" nowrap="nowrap">Date: </th>
          <td>Fri, 03 Jun 2011 14:44:05 -0400</td>
        </tr>
        <tr>
          <th valign="BASELINE" align="RIGHT" nowrap="nowrap">From: </th>
          <td>Nate Fries <a class="moz-txt-link-rfc2396E" href="mailto:nfries88@yahoo.com"><nfries88@yahoo.com></a></td>
        </tr>
        <tr>
          <th valign="BASELINE" align="RIGHT" nowrap="nowrap">To: </th>
          <td>Joachim Durchholz <a class="moz-txt-link-rfc2396E" href="mailto:jo@durchholz.org"><jo@durchholz.org></a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <pre>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.
</pre>
  </body>
</html>