9 ms·

It seems cool but why would you use it instead of having a c lib (or c obj file) interfaced with ctypes or swig ... ? Maybe I miss what LLVM brings ? Thanks

• cdavid 14y ago
  once you can import llvm code at runtime, you are pretty close to injecting llvm code at runtime: you write some LLVM IR in a string, and "llvm_eval" it.
• wzdd 14y ago
  I addition to cdavid's comment: LLVM IR is system independent. So if you had a deployment over heterogeneous machines you could write the extension code once and have it run everywhere without recompilation.
  • horsetail 14y ago
    LLVM IR is not system independent. http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independent-llvm-bitcode http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-p...
    • wzdd 14y ago
      Fair enough, that was too strong a claim. But it is more portable than an extension module compiled with the system compiler.
      • tungstentim 14y ago
        It's not portable enough to let me take IR generated for my x86 laptop and run it on my arm board, in general, even though both platforms are ILP32, little-endian, and running the same OS.
        • wzdd 14y ago
          Yes, but this is a problem with the source language and/or the host system libraries, not with LLVM IR itself. There is a broad domain of applications for which it is portable.
• radarsat1 14y ago
  I was confused about this too, but I think the idea is that it's easier to infer type information from the bitcode than from raw object code.
• jnazario 14y ago
  more closely related to ctypes than swig. swig requires glue code (.i files) to be written and generated, then compiled. ctypes can take a system native library (.so or .dll) and access it. bitey, on the other hand, uses platform-neutral llvm bytecode. imagine ctypes but platform neutral. that's bitey. pretty darned cool.