Crazy JIT Prototype is on hold.

G'Day

“Crazy JIT prototype” is on hold. I found 2 big problems with current approach. Which will require a quite big effort from me (or anyone else) to “fix”.

• Parsing of larger subset of C. Mostly of struct definitions and preprocessor.
  
• Type analyzes.
  

Let's start with first one. Parrot is very big, old and (sometimes) itchy codebase. For many years we (parrot's core developers) were using quite few macros to simplify our life. Just because plain C isn't most beautiful language in the world. For example VTABLE_foo(interp, pmc) to access VTABLE method foo is actually macros which expands to pmc->vtable->foo(interp, pmc). There is plenty of such macros. Many of them are auto-generated. Many are hand-crafted. To be able to parse some “generic op body” jitter will have to know about all of them. Which will require parsing of more C code upfront, “understand” bigger subset of C, etc. It's not a big deal to write it. Moreover it's mostly straight forward. But it will require a lot of effort. Second part (which is kind of closely related to first one) is type analyzes. For example pmc->vtable->foo(interp, pmc) should be represented as:

VTABLE *v = pmc->vtable;
v->foo(pmc, interp);

In terms of LLVM it's sequence of GetElementPtr calls. For accessing fields inside structure there is special version of this instruction called struct_gep. And this instruction requires to know offset inside “type of pmc”. Which requires knowledge of variable types during jitting. It's not a big deal for someone who can spend few months fulltime on this task. But it's a big deal for me.

So, for time being, I'm putting this JIT prototype on hold. Until after I can workout some simpler solution which doesn't require implementation of good 80% of C compiler. May be some “C based DSL for ops”, may be “generating C for whole jitted sub and use clang”, may be something else. We'll see.

Bye. And have a good one.