Monday, June 8, 2009

New backend.

The new C backend has been pushed to the repository and it seems to work without a hitch. No particular effort has been directed at making it efficient (and none will since this backend is only a temporary measure). Initial testing shows it to be around 40-50 times faster than the interpreter.
Writing this backend was surprisingly easy; low-level Grin (LHC's intermediate language) can be directly pretty-printing as C code. By far the hardest part was giving up on LLVM and settling for C.

Future development will focus on grin-to-grin optimizations and a native code generator.


  1. What problems did you encounter with LLVM that made you drop (or delay) it as a code generator?

  2. (1) Could not find a specification for the LLVM IR.
    (2) The type-system got in the way too often. (I'm saying this as a bondage-and-discipline loving Haskeller).
    (3) The language has quite a few oddities I couldn't wrap my head around. For example, 'ret X' and '%local_var = X \n ret %local_var' are not the same.

  3. Re 1: is what I use when coding in IR. Or do you want a more formal spec?

    Re 2: Yes, but in my experience static typing helped to catch A LOT of bugs.

    Re 3: care to elaborate? Do you mean that you can't do 'ret add %1, 2'? This isn't possible in assembly either.

    > Writing this backend was surprisingly easy

    Hearing this makes me want to try coding a LLVM backend myself. Would you accept such a backend into LHC if I wrote it?

  4. 23Skidoo:

    Re Re 1: Yes, the reference manual was helpful but a formal specification is essential.

    Re Re 3:
    This is valid:
    ret i32 0

    But this isn't:
    %local_var = i32 0
    ret i32 %local_var

    This is valid though:
    %local_var = bitcast i32 0 to i32
    ret i32 %local_var

    There may be a perfectly reasonable explanation for this but without a specification you wouldn't know.

    Re LLVM backend:
    Oh yes, absolutely. Contact me on email or irc and I'll help you in any way I can.