Now that I'm getting a little more familiar with the guts of the compiler, I
can see some things that would make things much simpler for me, and may be
useful for other people. I'd like to re-factor the compiler even more than I've
done right now.
First, one problem I'm having right now is that I don't have a firm grip on the
AST of the backend. There are many many options, and I'm not sure how they all
mix together. While there are scripts like flxd and flxb to print out the
current state of the AST, it's converted into almost-compilable felix that
doesn't really help. What I really want is to really just see the AST in some
s-expressions. So why don't we add two ways of displaying the AST? And if the
AST s-expressions can completely represent the AST, we could read it back in.
I'm thinking about using sexplib to get AST -> s-expressions for free. It's a
small library, and since I'm basing my work on the huge llvm, it doesn't seem
like it's that much. The only real problem I can think of is the near name
collision with the sex module. Maybe we could rename sex to flx_sex. We could
also have a binary done via marshal.
Second, the compiler is very monolithic, but it doesn't have to be. There are a
couple high level concepts that we could break out into their own separate
libraries:
1. reading and typechecking the flx files
2. reading (and not typechecking) the AST s-expressions
3. writing out the AST in felix
4. writing out the AST in s-expressions
5. converting the AST to c++
6. converting the AST to llvm
7. shared data structures
Then, using these libraries, we can implement some new drivers:
1. flx-as (as in felix assembler) that does .flx -> AST
2. flx-dis (as in felix disassembler) that does AST -> .flx
3. rename flxg to flxc-cpp (as in felix compiler) that does {.flx,AST} -> c++
4. rename flxg to flxc-llvm (as in felix compiler) that does {.flx,AST} -> llvm
5. create flxc that can do {.flx,AST} -> {c++,llvm}
The nice thing about library-itizing felix is that it becomes much easier to
write tools to process the AST. For instance, making a doxygen-like document
viewer would be much simpler when we could just work directly with the AST,
rather than re-parse it like the old viewer used to do. Another long term thing
could be gui integration. I think there could be a lot that we could get out of
this.
Third, I'd like to at least push converting matches into gotos into the
backend. Llvm needs to but at the end of every basic block, but the felix
frontend assumes that gotos can fall through. I'm ignoring support for
arbitrary gotos at the moment. Will bad things happen if I do this? Are there
other things that should be pushed to the backend?
Fourth, and this one's tentative, I might try to use my fbuild in my llvm
branch. When I stopped working on it in January, it was configuring and
compiling ocaml. Since that's all I'm going to be doing with llvm for a while,
it might be nice to actually use it.
Fifth, where'd you all go? I hope we can get some more involvement to help me
with all this :)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
