Add a "hello world" test

[dr-m]

In an attempt to learn how to use this library, I tried to port https://github.com/dr-m/hellovm to it.

Apparently I am doing something wrong, because both the interpreter and the compiler front-end are triggering a SIGSEGV when trying to invoke the generated code, on AMD64. Is the problem simply that I am reusing some registers, that is, violating the SSA (static single assignment) form? I understand that adding diagnostics (even as a compile-time option) could be against the goals of this project.

Because no other test is covering the function MIR_new_call_insn(), this program (once it has been cleaned up) could be a useful addition to the built-in test suite.

[vnmakarov]

Thank you for your interest in MIR-porject and sorry for the delay with the answer (I am busy on other project until May).

In an attempt to learn how to use this library, I tried to port https://github.com/dr-m/hellovm to it.

Apparently I am doing something wrong, because both the interpreter and the compiler front-end are triggering a SIGSEGV when trying to invoke the generated code, on AMD64. Is the problem simply that I am reusing some registers, that is, violating the SSA (static single assignment) form?

SSA is used only internally in MIR-generator. So you should not worry that MIR reg should have one definition only.

I understand that adding diagnostics (even as a compile-time option) could be against the goals of this project.

Low level programming is not easy (especially JIT). You can look at MIR as the assembler. When you use assembler, it is easy to write a code giving SIGSEGV too.

There are a lot of diagnostics in MIR-generator. It is the most complicated part of the MIR code. You can see it when you use c2m with -dg option.

You could also compile MIR with -DMIR_INTERP_TRACE=1 to check execution of every interp instruction. The interpreter will print insn and its ops right before the execution.

Because no other test is covering the function MIR_new_call_insn(), this program (once it has been cleaned up) could be a useful addition to the built-in test suite.

Thank you. I'll look at your code and write you back today what is wrong with it (or may be it is a bug of MIR, who knows).

[vnmakarov]

The problem with the code is wrong place of func and return value. Call insn operands are: proto called function return value args

With the right place of called func and return value operands, you code works as expected.

[dr-m]

Thank you for your help! I updated the program based on your advice. I realize that there is not much that can be done to protect against this type of a mistake, because unlike LLVM IR, MIR has rather liberal implicit type casts.

The program now almost works in both interpreted and compiled mode (selected by modifying the #if in the source code).

LANG=C make hello-test
gcc -I. -fPIC -g -std=gnu11 -Wno-abi -fsigned-char -fno-tree-sra -fno-ipa-cp-clone -O3 -DNDEBUG -DMIR_PARALLEL_GEN  mir.o mir-gen.o mir-tests/hello.c -o ./hello-test -lm -ldl -lpthread && ./hello-test
hello
world
goodbye
world
make: *** [GNUmakefile:354: hello-test] Error 26

The 26 is the number of characters written. Actually, I intended it to write "all" as the last word. I will debug and fix that later.

Which command line option would you prefer for specifying whether to use the interpreter or the generator? How would you suggest to modify this to look and feel more like the existing tests or examples? I see that there are .expect files only in c-tests, none in mir-tests.

[dr-m]

I implemented a simple command line parser, modelled after mir-tests/run-test.c. By default, the program will dump the generated MIR code. With the option -i or -g the generated code will be executed either in interpreted or generated form.

[vnmakarov]

Thank you for the test. You've chosen the right directory for the test. I've merged your PR.

[dr-m]

Thank you very much!