--- Begin Message ---
Pippijn van Steenhoven wrote:
On Sat, Aug 15, 2009 at 05:54:29PM -0500, Richard Pennington wrote:
I've been working on an Elsa (not pork) port. I'll add my 2 cents.
My port integrates elsa and LLVM (http://llvm.org) for code generation
for multiple processors.
That is *very* interesting. Where can I read about your project? I had
similar plans with elsa. If you're already working on that, I might be
able to help.
http://ellcc.org (probably out of date)
1. restructure source tree, use autotools
I'm working on using cmake. autotools is too complicated for my tiny
little brain.
I have been using (gnu) make for a long time and got used to it. It would
allow things like distributing a elsa library that can be used by
different programs (pork, oink, your llvm thing).
I've been using (gnu) make for a long time too. It's just that automake
and friends seem to add a lot of complexity.
LLVM is already buildiable by cmake.
2. remove smbase string
Great idea, but make sure you replace it with something the make unique
string pointers for performance.
I already did it, I replaced it with std::string. I had a slight
performance increase but I didn't test very extensively. I also lost the
work during a hard disk crash, but I know it can be done in an hour,
maybe two.
4. remove even more smbase ADTs and use boost:: ones
Hmmm. I'd not like to have to rely on boost. Of course, I rely on LLVM
so I might be the wrong guy to complain. ;-)
smbase has things like boost::ptr_vector. I'd like to use the boost ptr
containers for most (all, if possible) elsa-types. It also has a
refcounted pointer that is exactly like boost::intrusive_ptr (not in
TR1). I don't think (but I might be wrong, it's been a while) that it is
currently using an std::tr1::shared_ptr equivalent but I wouldn't object
against introducing it and removing all manual deletes (however I would
prefer boost::intrusive_ptr for efficiency).
5. remove some unused or unneeded parts of elsa (they have some weird
macro support I don't think actually works)
I've replaced the elsa lexer with the LLVM project clang preprocessor,
works like a charm. It does keep track of macro contexts.
The macro stuff I am talking about here is nothing like C macros. Look at
cppundolog.cc and lexer.lex. They are like:
/*<foo/
bar>*/
/*!foo/
/*mfoo/
I'm not exactly sure what it does, but I don't need it and I have not
seen anybody use it, so I don't see any reason as to why it should be
there.
I really stripped out all of the elsa lexer and replaced it with the
clang lexer. The preprocessor is now completely integrated into elsa,
not a separate pass.
6. remove XML in/output from elsa (yes, it's nice, but it's for the
best and can easily be replaced by "my $xml = XMLout($ast)" after
integrating elsa with perl
This might be a mistake for use by other processing systems. If your
really stuck on perl, I guess. My xml support is bitrotted and diabled
right now, anyway.
Possibly. I have thought about just using the XML as input for perl. I
have actually done it, too, but I thought it would be nice to have...
I'm not too interested in XML output, hence the bitrot. I've been
thinking about doing static analysis by linking elsa output modules.
7. add (intrusive) perl support to elsa's AST
Hmm.
...intrusive support, so it can modify the AST directly and intervene
with any part of the parse and typechecking process. I would certainly
agree with making it optional. It would be another .ast file that could
simply not be included.
The state of my stuff is that it is a pretty complete gcc computable C
(not C++ yet) compiler that can generate the LLVM IR. I've been
compiling and building programs with newlib and running them under
Linux. The nice thing about LLVM is that I can compile the whole program
(libraries and all) into IR and generate code after the whole program is
linked together. 1 .s and 1 .o file for the whole thing.
I am totally in love with LLVM. I use it as one of the backends of my
code generation and optimisation library (just a fun project I work on at
university). I am also playing with the "pure" programming language which
uses LLVM and working together with the felix developers one of whom is
helping out with LLVM and working (worked and is soon going to work) on
LLVM as a felix backend as opposed to the current C++.
Right now I'm compiling code for most of the LLVM backends (some have
unimplemented parts). I've also added a backend for the Altera Nios2.
As I said, there are parts of my plans that might be interesting to
others, so I would like to share those. Whatever I do after that is
mostly up to me and probably not interesting to anybody but me and some
odd perl freaks (one of which I am). I did all of this once.. in complete
silence. Next time I do it, I want to share it (it won't get lost in a
hdd crash then ;) (unfortunately for me, I did not backup this, yet. I
did all that in a few days and I do backups every friday)).
-Rich
--- End Message ---
