search

vnmakarov / mir

A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
MIT License
2.29k stars 145 forks source link

Any planned release of the project in the near future? #105

Open sletz opened 4 years ago

vnmakarov commented 4 years ago

A few months ago I had a plan to make the first release this summer and wrote about this. Unfortunately I am busy with other projects. So it will not happen. Sorry.

Now I can only say that the release will be this year and I will seriously work to make it happen before the year end. Sorry again.

sletz commented 4 years ago

Thanks. I have a possible use-case for MIR in an audio plugin that I'm contributing to right now: https://github.com/sletz/VCV-Prototype for the VCV Rack application, using the Faust audio DSP language in dynamic mode, that is with the compiler embedded and a JIT to produce executable code on the fly. Using LLVM will be complex in this context, so I was wondering if our (already written..) MIR backend could be used instead.

How stable is MIR now? I've tested successfully on OSX. Does it run also on Windows and Linux ? Thanks.

vnmakarov commented 4 years ago

How stable is MIR now? I've tested successfully on OSX. Does it run also on Windows and Linux ? Thanks.

I think MIR is stable. I know only one wrong code generation problem with loop invariant motion optimization (-O3). I did not work on this problem yet. On the other hand I am thinking about removing LICM because it does not give an improvement I expected and it is a lot of complicated code.

MIR (and its API) will be probably extended but I think compatibility will be kept.

C2MIR will be less stable as I am working to implement target ABI compatibility. x86-64 ABI is particular hard to implement.

LLVM2MIR is not finished yet (.e.g. no LLVM IR aggregate translation was implemented). I also know that SSA lost copy problem exists in this translator. It means in rare cases a wrong MIR code can generated from LLVM IR.

I don't know about Windows port. This port was done by logzero for his own purposes. I'd like to tackle Windows port for the release but never started this work yet by myself.

Linux/MacOSX x86-64, linux ppc64be/le, aarhc64, and s390x are tested after each push and nobody reported any wrong code generation problem with them which was not resolved.

sletz commented 4 years ago

Thanks for the summary.

@logzero can you possibly describe what is the situation on Windows? Thanks.

logzero commented 4 years ago

Mir gen works (for me). Interpreter should work too. Real long doubles and multiple return values are not supported (would be extensions to Windows ABI).

I've toyed around with cmir, mostly to get more tests to run, but haven't had much time for it lately.

One thing I haven't pushed yet are the changes to the Makefile to make it build under Windows/msys2.

logzero commented 4 years ago

And I haven't tested the llvm bits at all, don't use them.

dibyendumajumdar commented 4 years ago

Mir gen works (for me). Interpreter should work too. Real long doubles and multiple return values are not supported (would be extensions to Windows ABI).

I've toyed around with cmir, mostly to get more tests to run, but haven't had much time for it lately.

Interesting - I had assumed that your work was in incomplete.

One thing I haven't pushed yet are the changes to the Makefile to make it build under Windows/msys2.

I use CMake/MSVC and if I build on Windows would it work? Is there anything special about msys2?

Thanks and Regards Dibyendu

logzero commented 4 years ago

I use CMake/MSVC and if I build on Windows would it work? Is there anything special about msys2?

You'd have to write the cmake script. Msys2 (mingw/gcc) is a bit more linux/posix friendly. Mir is built with -std=gnu11. The worst that can happen is that msvc complains about unknown functions (variants). But that is easy to fix too.