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.24k stars 147 forks source link

Files under https://github.com/vnmakarov/mir/tree/master/c2mir are not platform-independent. #159

Open lygstate opened 3 years ago

lygstate commented 3 years ago

Better to using triple to create platform-independent compiler, that's is a single compiler that can cross compiling to multiple target triple.

vnmakarov commented 3 years ago

Thank you for the feedback. Currently I am not planning to implement cross-compilation. The only meaningfull output for cross-compilation now is MIR textual or binary form.

You are the first who proposed this. So I think it is not that valuable feature for the current users of MIR project even for people generating C and then getting JITted code with c2m.

In the future, c2m might support the cross-compilation but it will be definitely not implemented for the 1st release. It can be a useful feature if I implement asm generation for c2m as someone already proposed this.

RussellHaley commented 3 years ago

I am thinking about a hypothetical arm 32 bit bare metal platform. How would I write C on a HOST x86_64-linux-gnu that would run on arm-none-eabi? I also wonder if my understanding of JIT and "running" is correct?

I would think there could be a few possible scenarios:

OR (dreaming) JIT the code on the HOST, send only a portion of the MIR code, and then *lazy load it across the serial port?" Oh my God: my brain just exploded. I wonder about garbage collection and memory management? No matter, I'm nowhere close to that. Could you provide thoughts on how I might achieve the above scenarios?

I am also now split between two issues (and clearly following @lygstate around!). @vnmakarov, are git issues your preferred communication? Should I open one issue for arm bare metal?

vnmakarov commented 3 years ago 
* Stream C code over a serial port and "JIT" it on the target. That is, convert the C to MIR and then interpret it.

* JIT the C code (e.g. convert to mir) on the x86_64-linux-gnu host and then stream the mir code over serial to the target (interpreter).

C to MIR translator is slow and has a big memory footprint. It was not designed for fast compilation (still c2m front--end is faster than GCC/LLVM frontend) because it is a multi-pass compiler with a verbose IR. I think it is better to use MIR when it is possible.

Could you provide thoughts on how I might achieve the above scenarios?

Writing a new port (e.g. 32-bit arm) is a big job. Even for me it would take 2 months of my work (it is code generation, implementing ABI, all requiring lot of attention to many low-level deatils). Porting only MIR-interpreter is smaller but also non-trivial task but more double There is machine-dependent code (e.g. mir-ppc64.c) for this. This code provides C-interface call for interpreted functions, C FFI, and other some minor target-dependent thing.

I am also now split between two issues (and clearly following @lygstate around!). @vnmakarov, are git issues your preferred communication? Should I open one issue for arm bare metal?

I prefer well-defined focused issues to work on it and reflect the progress of this work. Although there can be some issues with long discussions.