Open assyrianic opened 4 years ago
Thank your for informing me. I glanced at your project. It looks interesting.
I see two issues to use MIR JIT, it can significantly increase TAGHA code size. Another issue MIR is still in active development. I am planning to do the 1st release only in summer (probably in August). One more thing. If you are going to use MIR in your project , your probably need to modify MIR sources. For example, you would not need the MIR-interpreter as you have own one.
significantly increase code size, by how much really? I mean if someone is going to use the JIT portion, they likely would'nt care about the code size.
Also, how fast is the MIR-interpreter compared to Tagha?
significantly increase code size, by how much really? I mean if someone is going to use the JIT portion, they likely would'nt care about the code size.
I wrote about the size because TAGHA is advertised to be small, only 50Kb.
mir.o
andmir-gen.o
(minimal code to use MIR) is about 300Kb. Also, how fast is the MIR-interpreter compared to Tagha?
I don't know. MIR-interpreter was not designed for very fast speed. MIR_val_t has size of long double
(128-bit on some targets) although for the most values 64-bit would be enough.
MIR-interpreter was designed to be used with MIR-generator. This makes calls in MIR_interpreter slow. Basically MIR function calls are implemented through FFI because MIR function execution can be switched from interpretation to execution of the generated (JITted) code and therefore the same call ABI (C function call ABI) should be used.
Is the MIR-interpreter and the JIT tied together? Can you use the generator as just a backend to binary compiler(i.e in place of clang).
Is the MIR-interpreter and the JIT tied together? Can you use the generator as just a backend to binary compiler(i.e in place of clang).
Sorry, I don't understand what do you mean by 'tired together'. You can execute MIR code in the interpreter or generate binary code and execute it. Generally speaking, you can interpret MIR function and then decide to generate binary code and execute it instead.
Having fast generator (the fast generator works when zero optimization level is used) there is probably no sense to interpret MIR-code anymore as the fast generator generates code very quickly and the generated code is several times faster than its interpretation (especially when there are calls in MIR-code). Although MIR-interpreter can be still useful for debugging and development purposes.
MIR-interpreter is not more portable than the generator as it needs FFI for calling external functions. FFI is a machine- and ABI- depended generated code (you can find code generating the FFI in mir-<target>.c
files).
As for using MIR instead of llvm, it is not possible yet as MIR does not generate assembler or some object format (e.g. elf). There are some plans to generate assembler in the future because it is not a big project. Still I would not say after that it could be used instead of llvm. LLVM additionally can generate PIC code and represent debugging info (e.g. dwarf). Implementing this for MIR is a really big project.
Still you can generate standalone executable with MIR already with b2ctab
utility. You can see how it is done for c2m
in Makefile entry c2mir-bootstrap-test3
. The executable is basically MIR-code (with generator), some MIR binary code as C array, and driver (small C program) which uses the generator to create machine code from the MIR binary on the fly and to call the machine code.
Meant "Tied" sorry for the typo.
hey Mr. Makarov, I wanted to do an update that I've refactored TaghaVM with a brand new architecture that I believe would make it easier for MIR to JIT compile. Here's an example using C code and the Tagha Assembly equivalent!
int main(void)
{
int count = 0;
for( int i=0; i<iterations; i++ ) {
count = add_one(count);
}
}
;; int add_one(const int n);
$native add_one
main {
alloc 4
movi r3, 1000000000
movi r0, 0
movi r2, 0
movi r1, 1
.loop:
call add_one
sub r3, r1
cmp r3, r2
jz .loop
redux 3
ret
}
I've designed it to be similar to Register/SSA IR that are usually used in JIT and AOT compilers!
hey Mr. Makarov, I wanted to do an update that I've refactored TaghaVM with a brand new architecture that I believe would make it easier for MIR to JIT compile. Here's an example using C code and the Tagha Assembly equivalent!
Thank you for the info. It looks interesting. I'll try to find time to look at this more.
hello. I'm the developer of a 64-bit, RISC, register-based virtual machine called Tagha and I've been watching MIRs development for some time and I'm interested in using MIR as Tagha's main JIT.
To give a brief summary. Tagha has 32, 64-bit registers. Uses a stack for calls, and its written entirely in C(99).