I’ve seen some interesting articles on implementing with just the assembly language:
& a bunch of others. But everything I see is written for one architecture, OS, endianness &etc.
Whereas LLVM IR is a ‘level above’. How about using LLVM IR as a language for ‘regular development’? - E.g., build a web-server, build a RESTful web-framework, build database interfaces, &etc; all in LLVM IR. Along the way build some package management and build helpers (CMake/ninja I guess).
Not sure if this is more of a hobbyist project idea or if it has legs as a proper prospect. Interested in your opinion.
I used to think as you do but the unstable C++ ABI makes it unsuitable due to compatibility breaking decisions that crop up from time to time. The PNaCl project tried to preserve a sustainable bitcode format across different versions of LLVM but proved unsustainable. The WASI ABI of WebAssembly is designed more like you describe. The Wasmer runtime is very flexible and supports multiple languages on the frontend.
I believe that the issue with PNaCl was more about a need for forward compatibility than anything else: LLVM does not provide this and is only backward compatible with previous bitcode. Apple relies on backward compatibility for the App Store and it seems to be working fine.
So I don’t think the PNaCl experience really relates here for a project that would be written in LLVM IR assembly instead of x86 assembly for example (neither how I can see how the C++ API instability matters…).
On the other hand, it seems to me here that the major hurdle is more than LLVM textual assembly isn’t backward compatible but locked to a particular version of LLVM. If you write your source code in LLVM assembly, you will “forever” need a toolchain that serialize it to bitcode before feeding it to clang/llvm at least as recent as the version you wrote the assembly for.