It's great to see MoonBit adopt llvm, but is it relying on a c compiler or independent?
LLVM Back End for MoonBit
11–20 of 20 posts
Re: LLVM Back End for MoonBit
#12[dead]
[dead]
Re: LLVM Back End for MoonBit
#13It's great to see MoonBit adopt llvm, but is it relying on a c compiler or independent?
"Once support for distributing precompiled runtime libraries is implemented, MoonBit programs will be completely independent of the C compiler, generating native executables using only a linker."
Re: LLVM Back End for MoonBit
#14[deleted]
Re: LLVM Back End for MoonBit
#15How does MoonBit’s LLVM backend compare to Zig or Rust?
[dead]
Re: LLVM Back End for MoonBit
#16[dead]
Re: LLVM Back End for MoonBit
#17MoonBit supports the LLVM backend. With this, it achieved 8× Java’s performance in FFT and introduced out-of-the-box debugging with DWARF symbol injection, enabling precise source mapping directly to compiled outputs. MoonBit will soon compile directly to native binary files without relying on a C compiler. This eliminates various compatibility issues associated with C compilers.
Does this mean MoonBit will get JIT support soon?
we have a interpreter mode which takes advantage of tcc for fast interpretion
Re: LLVM Back End for MoonBit
#18I assume there was a C backend before — some numbers comparing that and the wasm backend with LLVM would’ve been helpful."
The LLVM mode currently is not good as C backend, but we are working on it to bring it comparable to C backend
Re: LLVM Back End for MoonBit
#19It's great to see MoonBit adopt llvm, but is it relying on a c compiler or independent?
we used to output C for native backend support
Re: LLVM Back End for MoonBit
#20Wonder how the LLVM backend affects compile times. Anyone tried it yet?
it is not the optimial, for fast native mode, we rely on tcc for fast interpretion