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.
February 7th, 2005 at 10:05 am
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?
February 7th, 2005 at 11:52 am
I’m pretty sure Debian knows what Happiness is.
February 7th, 2005 at 12:33 pm
Come to think of it, you’ll probably also need the garbage collector
library, “apt-get install libgc-dev”…
February 10th, 2005 at 2:57 pm
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…)
February 11th, 2005 at 2:07 pm
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!
February 11th, 2005 at 7:08 pm
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.
February 14th, 2005 at 9:48 am
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…
February 14th, 2005 at 10:06 am
If you type ‘make’ in the ExTT directory it should then work how the script says
February 14th, 2005 at 12:40 pm
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.
February 14th, 2005 at 12:52 pm
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
February 17th, 2005 at 4:29 pm
Seems sensible to put it in CVS. If the permissions work, I’ll put it in some sensible place…