If I got this right, can I import MIR binary files as modules and use them as libraries (.so)?

[rempas]

Hello again! I'm reading a little bit about the spec in MIR.MD, briefly. At this point, I want to first finish my front-end to a point (at least functions, variables, function calls and branches) and then properly read the spec and start creating a "full" compiler. However, one thing I got interested in was how I can emulate "shared object libraries" in MIR. And say "emulate" because from what I know, there is no such type in MIR.

So from what I read, I understood tho things:

• We can read a Binary Mir file using the MIR_read (MIR_context_t ctx, FILE *f) function.
• A Mir program consists of modules and these modules are added to the programs context (right?).

I don't know if it's written somewhere (and I just missed it because I didn't gave much focus yet) but I guess that a binary file that the MIR_read (MIR_context_t ctx, FILE *f) function reads, is treated as a module and it is added to the context that is passed in the parameter "ctx". And when we use the MIR Generator, it just generates the context so everything is included.

So If I get it right, I can "fake" and treat MIR binary files as libraries. Is this right or do I miss something?

Again, sorry for having you read all that and answer but I would like to be as sure as possible so I don't have to change the design of my compiler later cause it is very clear to me that changing the design has been a nightmare to me so far (I still don't have a program that can execute after so many weeks...). Thank you!

[vnmakarov]

• A Mir program consists of modules and these modules are added to the programs context (right?).

Yes, modules are the highest level entities of in the context.

I don't know if it's written somewhere (and I just missed it because I didn't gave much focus yet) but I guess that a binary file that the MIR_read (MIR_context_t ctx, FILE *f) function reads, is treated as a module and it is added to the context that is passed in the parameter "ctx". And when we use the MIR Generator, it just generates the context so everything is included.

File can contains more than one module. All modules from the file are added to the context by MIR_read.

Before generation of machine code for functions in a module you need first load the module by MIR_load_module. This will allocate memory for data and bss in modules and make exported module entities (functions, bss, data) visible for other loaded modules.

After that you should link everything loaded by MIR_link. It links imported and exported entities from different loaded modules. Depending on used interface (an arg of MIR_link), MIR_link generates code for all funcs of loaded modules or just prepare to generate code each funcs on their first call.

So If I get it right, I can "fake" and treat MIR binary files as libraries. Is this right or do I miss something?

Yes, MIR binary files can be considered as libraries with own format. The only difference from traditional libraries is that MIR-generator still can inline functions from the binary files when it generates code for a function calling the functions from binary file.

[rempas]

Once again, thank you for your answer! Writing my frontend is HELL itself as I'm trying to optimize things as much as I can (at least as much as I can think) right away so I don't have to change my program later (which has been proved to be annoying). And on top of that, my language will be very advanced which makes my job even harder. If I had to also write a backend, I don't think I would start the project at all....

It's thanks to things like your Mir and QBE that I had the courage to even think about making the project. However, compared to MIR and you, I don't have the same sympathy for QBE. This is because I have sent two emails in QBE's mailing list and after them, I have come to the conclusion that QBE's maintainer doesn't care a lot if people are going to use QBE and isn't willing to help and consider adding new features other than the ones he wants to add (however he asks if we want any features anyway, lol!) . Of course no offense to QBE, I'll talk about it later. Now about the emails:

In the first one, I got no answer (I asked something about the optimizations QBE does or something like that, I don't remember exactly as some months have passed). The second was a reply to an email talking about QBE's first release and the maintainer asked if there are any features we would like to get implemented before the release (or if we want to say anything regardless of QBE at all). I talked about system calls and why I need them and I got a straight "NO"!

Of course, the maintainer (and other people) listed some reasons but the thing is that, I cannot make them myself as there is only an ugly way to work around this (or link with libc which is a big no). That or, having another assembly file that contains the functions (labels) that will allow use to make a system call (check here). However, as you can see in the file I've sent you, this methods also requires to further move the registers as the function calling conversion (at least the SYSV one) passes the first argument to RDI, the second to RSI, etc. Which the system calls have RAX as the first argument, RDI as the second, etc. And that's on Linux, on other systems, we'll have to have other files that will be compiled and linked instead. It makes sense for the IR to handle that rather than having every frontened developer having to do that. Keep it in one place and share it philosophy!

Of course, this is not meant to rant, QBE (as I said before). They do what they want with their project and this makes sense. I'm just explaining my views behind my choice. In contrast, you happily answered all of my questions and you seem to understand that I don't ask for some stuff because for the sake of asking for more features but because we really do need these features and you are seeing how we need these features yourself. On top of that, this is a great move as this will make a better image for MIR making it seem a complete and mature IR!

You are in general open to discussion and that's a good think and definitely one reason to like and promote MIR! And what's funny is that, you created MIR to use it with Ruby so you already had a goal in mind and It wouldn't be weird to me if you didn't cared about other people creating frontends for it. Yet, you are more supportive than the other generic IR that I mentioned. IMHO (where 'H' stands for "humble" and not "honest"), MIR has the perspective to become replace LLVM and be a better IR for every language frontend to use making finally the creating on a good compiled language not so HARD.

Thank you for reading this. Happy coding my friend!

[vnmakarov]

QBE is an old project and it is hard to support project for long time. I myself have too much technical debt acquired (the biggest one is GCC RA) and can not spend much time on MIR project as I want.

I don't think MIR will be a competitor for LLVM. The resource difference is simply enormous. On resource base I am even far away from webassembly or cranelift and I would like to become a competitor just for them.

[rempas]

It's fine! You don't need to work many hours a day or not even work on it every day. Every project needs time to bloom and mature! MIR may be able to give you 80% of what LLVM does some day. The most important thing is to have fun working on it! And I hope you do my friend!