Feature request: Can you instuctions for syscall and interupt?

[rempas]

From what I've seen, there are no built-in instructions for system calls and interrupts so could you consider adding them? We could probably get away with them by creating libraries in assembly and link with them but this is very clunky and doesn't feel good at all. I had the same problem with QBE and they didn't want to add it took. Tho, in QBE, you'll at least use assembly files and won't have to generate an ELF library which makes things a little bit better (still not as good as built in however).

[vnmakarov]

Thank you for your feedback. There were several proposals to add new MIR insns. It is a pretty common request.

I'd like to have a general solution for this. GCC has asm extension. It is probably too much as it practically requires assembler implementation. So I am thinking about simpler solution. I have some ideas but did not figure out the final solution yet. But I'll work on this as it is important feature for me too.

[rempas]

Yeah, of course it's important for you as especially system calls will allow us to be clean from having to link with libc. Thanks for your work!

[rofl0r]

clean from having to link with libc

.. which is only an advantage (and a small one at that) if you dont want to link with any libraries written in C, unless they themselves use nothing of libc. otherwise your program has to go through C startup code anyway to have global structures like malloc heap, etc, set up. in the long run it's much easier to call e.g. libc write() instead of hardcoding per-abi syscalls in asm.

[rempas]

I see your point! You are right but it will be useful for new programming languages that will create a system library and then the libraries in this language will use it so no libc!

Of course if you are making a language and you don't want to create a system language or you create a C frontend then there is no reason on doing that.

[snej]

From another thread, the answer for calling external code is:

To call external functions (e.g. from .so or .a library or code which uses libmir.a) from MIR code, your need to provide import_resolver function to MIR_link function call. When MIR_link links MIR code and see external (imported) functions/data reference and cannot find such functions/data in already loaded MIR code, it calls import_resolver to get the address of the external function/data.

So you’d write a tiny C function that invokes the syscall, and use that resolver to link a Mir function to it.

I don’t understand your point about avoiding libc, because whatever process is using Mir to run code already contains the Mir library, which is written in C and hence calls libc. Mir doesn’t produce standalone executables — it’s a JIT not an AOT compiler.

[vnmakarov]

I don’t understand your point about avoiding libc, because whatever process is using Mir to run code already contains the Mir library, which is written in C and hence calls libc. Mir doesn’t produce standalone executables — it’s a JIT not an AOT compiler.

I guess there is a point for automatic import of libc functions for C code. Currently c2m command automatically imports functions from libc and libm but it is not done on c2m API level. I think we could provide possibility to switch the same mode on c2m and may be on MIR API level. I'll think how to better implement this.