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.26k stars 145 forks source link

Assembly or ELF object output #87

Open michaelforney opened 4 years ago

michaelforney commented 4 years ago

I was wondering if there were any plans to add assembly or ELF object output support to MIR, or if that is out of the scope of the project.

Although you are mainly focused on JIT compilation, I think these output formats would be quite useful for ordinary compilers. For instance, I am interested in using MIR as an additional backend for my C frontend, cproc (currently I'm using QBE).

vnmakarov commented 4 years ago

Thank you for raising this question.

My major concern is to keep the code base small. For example I threw out a lot of code from mir-generator because of small value/code ratio.

In case of generating assembly code, the value/code ratio is big as the added code will be pretty small. So I think I will work on it although it will be not my high-priority task. Generation of assembly can make standalone executable smaller (now you can also generate standalone executable but it will contain all mir binary too). Generating assembly would also help me in debugging/development process.

I would only add that generating PIC assembly code would be a bit more more challenging task and this hardly will be implemented soon. Generation of debugging info (e.g. dwarf) would even more challenging. So I don't think it will implemented.

I am just curious why you want MIR instead of QBE. An year ago I looked at QBE and I liked it more than any other MIR competitors I mentioned in README file. Although I have no real experience of work with it. So your opinion about QBE would be interesting for me.

michaelforney commented 4 years ago

In case of generating assembly code, the value/code ratio is big as the added code will be pretty small. So I think I will work on it although it will be not my high-priority task. Generation of assembly can make standalone executable smaller (now you can also generate standalone executable but it will contain all mir binary too). Generating assembly would also help me in debugging/development process.

Yeah, I agree that assembly output would have the most value. I'd need it anyway to support the -S option in the driver.

I would only add that generating PIC assembly code would be a bit more more challenging task and this hardly will be implemented soon. Generation of debugging info (e.g. dwarf) would even more challenging. So I don't think it will implemented.

Both of these would be nice, but QBE lacks them as well, so that's probably fine.

I am just curious why you want MIR instead of QBE. An year ago I looked at QBE and I liked it more than any other MIR competitors I mentioned in README file. Although I have no real experience of work with it. So your opinion about QBE would be interesting for me.

I really like QBE, but its development is stalled at the moment. I've been struggling to get my local bugfixes applied, and it is missing several features I need to implement C (long double, stack restore for VLA, function inlining). So, I am exploring some other options.