cparser VS jstar

> QBE is a new optimizing backend much simpler than LLVM; cproc and cparser are two of the C compilers that target it, in addition to its own minic.

I thought cparser targeted libFirm. That's what their GitHub page says [0].

"It acts as a frontend to the libFirm intermediate representation library."

> We really need a production quality open source C compiler that is actually written in C.

I honestly think cproc or cparser are almost there already. For cproc, you just need to improve the quality of code optimization; it's really QBE you'd need to change. For example, you could change unnecessary multiplications by powers of 2 into left shifts, improve instruction selection so that subtraction is always something like "sub rax, rdi" and not "neg rdi / add rax, rdi" [1]).

For cparser, I notice slightly higher quality codegen; libFirm just needs more architecture support (e.g. AMD64 support appears to work for me, but it's labeled as experimental).

[0]: https://github.com/libfirm/cparser

[1]: I'm pretty sure this is the line of code that generates it, too: https://c9x.me/git/qbe.git/tree/amd64/emit.c#n418

[LAUNGUAGE: J*]

My language, obviously.

Also, since you are willing to look at non-treewalk interpreters, you can take a look at this: https://github.com/bamless/jstar/blob/master/src/vm.h In this I use two parallel arrays, one for frames and one for variables. The frame contains the instruction pointer of the function and the address of the start of the activation record. Variables are stored packed inside the stack array and are accessed through indexing.