On 22/05/2008, at 5:42 PM, Erick Tryzelaar wrote: > 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.
There are already routines to print both Felix Sexpressions and the raw AST. Some AST terms might be synthesised and have no corresponding Sexpression. > Second, the compiler is very monolithic, but it doesn't have to be. No, not really. It runs multiple independent passes, typically linked only by single "term" sent from one to the other plus some global cache (unfortunate). > 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 You can do this, but it is pointless and will damage performance. Marshalled data is typically unreadable except by the program that wrote it. Data written in specified format is portable but much more expensive to read and write. In both cases there is wasted I/O and conversion which will hurt performance, AND extra complexity maintaining the I/O code. Actually the raw AST_* expressions are not very important, they're fairly arbitrary rubbish representing the input syntax. The more important terms are the SYMTAB EXE_ etc terms (for the front end) and the BEXPR and BEXE terms for the optimiser and back end. BEXE/EXPR are a minimal "machine code" or "calculus" produced after lookup replaces text names with integer symbol table indices (effectively this is alpha-conversion). > > 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. This can already be done, the modules simply aren't built in groups called libraries because they only have one use (so reusability isn't required). > > Third, I'd like to at least push converting matches into gotos into > the backend. I think what is more appropriate is converting matches to switches in the front end and switches to goto in the back end. > Llvm needs to but at the end of every basic block, but the felix > frontend assumes that gotos can fall through. Huh? > 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? Felix uses goto because it is most general, it subsumes blocks. However, when blocks exist, an analysis routine would have to construct it. The optimiser should really do this -- convert the program into blocks, which is needed for many analyses, eg control/data flow. > > Fifth, where'd you all go? I hope we can get some more involvement > to help me with all this :) I'm still working on my boat.. I'm here .. though I just got a $2500 bill from Telstra for my wireless internet which is ABSURD. I may have to chuck that most useless and stupid of suppliers .. I can't believe how totally and utterly incompetent they are. -- john skaller [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
