Toy compiler

I’ve been writing a toy compiler, which sort of half works now, except that there’s no optimisations, the generated code is quite bad and the virtual machine is too slow - you can get it from http://www.dur.ac.uk/e.c.brady/extt.tgz. It spits out C, and you have to do a bit of work to get your program to do anything, but it’s a start (and at least there’s an example). I was going to spit out GHC core, but then I realised that writing abstract machines was too much fun.

Anyway, I thought I’d let you know just to show that I was actively doing something ;) .

It’s probably still worth having a GHC core back end, and certainly generating .hs/.hi files. But I think this way is going to work better for compile-time evaluation.

11 Responses to “Toy compiler”

  1. Conor Says:

    I was looking forward to playing with this, but on typing ‘make’ I discovered I couldn’t make the parser. I presume there is some suitable translation into debian of ‘forget your troubles, come on, get happy’ which will solve this problem. Does anybody know what it is?

  2. pwm Says:
    apt-get install happy

    I’m pretty sure Debian knows what Happiness is.

  3. Edwin Says:

    Come to think of it, you’ll probably also need the garbage collector
    library, “apt-get install libgc-dev”…

  4. pcc Says:

    Bug?
    6! = 720, but the code is producing 7! = 5040.

    NB the definitions of mult & fac are expensive - is this
    deliberate? (ie they analyse the larger arguments…)

  5. Edwin Says:

    The script does 6!, but my test driver does 7!. This is because NbE can’t cope with 7!…
    (or at least, I quit after it started using 512Mb…)

    As for the definitions; not deliberate, but also not thinking. It does make a huge difference!

  6. pcc Says:

    I’m a bit surprised that NbE takes so much memory, even for the expensive definitions. I would expect (at first glance) that even though the eliminators go through the bigger values, the whole
    thing is more or less `linear’. I mean, I would expect it to grab & free lots of memory, rather than keep big bits. Perhaps there’s a space leak in the NbE code? It might be worth careful profiling.

    Also, have you compared compiler output performance with Coq? It will be interesting to know what kind of factor change there is.

  7. Conor Says:

    My computer is now happy and can collect garbage. What I don’t quite get yet is how to gcc the output of the compiler to get an executable, so I can just have 6! like the script sez.

    It shouldn’t be too long before we adapt this to Frame…

  8. pwm Says:

    If you type ‘make’ in the ExTT directory it should then work how the script says

  9. Conor Says:

    Now I get the picture. The evals in test.tt get blatted out as compile-time diagnostics; I have to tweak testdrive.c if I want to run the compiled code on different examples.

    By the way, have we got the cvs permissions sorted out yet? It strikes me that a copy of the ExTT stuff ought to live here, if you’re happy about that, Edwin.

  10. pwm Says:

    CVS permissions were a bit of a nightmare, til we actually asked a sys-admin what to do, and now it works (fingers crossed). I suppose this would be a good test for it in any case ;)

  11. Edwin Says:

    Seems sensible to put it in CVS. If the permissions work, I’ll put it in some sensible place…

Leave a Reply