mir icon indicating copy to clipboard operation
mir copied to clipboard

MIR & Tagha

Open assyrianic opened this issue 4 years ago • 8 comments

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).

assyrianic avatar Apr 14 '20 19:04 assyrianic

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.

vnmakarov avatar Apr 15 '20 03:04 vnmakarov

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?

assyrianic avatar Apr 15 '20 17:04 assyrianic

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 and mir-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.

vnmakarov avatar Apr 16 '20 02:04 vnmakarov

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).

thysultan avatar May 23 '20 22:05 thysultan

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.

vnmakarov avatar May 27 '20 21:05 vnmakarov

Meant "Tied" sorry for the typo.

thysultan avatar May 28 '20 20:05 thysultan

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!

assyrianic avatar Jun 29 '20 21:06 assyrianic

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.

vnmakarov avatar Jul 06 '20 15:07 vnmakarov