I'm a little further along now. I've started to put together a simple
driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I
think
it works).
The file being compiled is a "printf" function. Here are timing
results
for optimized and unoptimized runs:
[~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions
Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
test/ofmt.i is ignored during this phase
Phase: Translation
compile test/ofmt.i to become an unoptimized LLVM bitcode file
typechecking results:
errors: 0
warnings: 0
Phase: Optimization
optimize ofmt.bc to become an LLVM bitcode file
Phase: Bitcode linking
bclink ofmt.bc to become a file that has been linked
Phase: Bitcode assembly
ofmt.bc is ignored during this phase
Phase: Assembly
ofmt.bc is ignored during this phase
Phase: Linking
ofmt.bc is ignored during this phase
===-------------------------------------------------------------------------==
... Ellsif action timing report ...
===-------------------------------------------------------------------------==
Total Execution Time: 0.2120 seconds (0.2143 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall
Time--- --- Name ---
0.1400 ( 72.9%) 0.0160 ( 79.9%) 0.1560 ( 73.5%) 0.1558 (
72.7%) Type checking
0.0280 ( 14.5%) 0.0000 ( 0.0%) 0.0280 ( 13.2%) 0.0310 (
14.5%) Optimization
0.0080 ( 4.1%) 0.0040 ( 20.0%) 0.0120 ( 5.6%) 0.0154 (
7.2%) Elaboration
0.0120 ( 6.2%) 0.0000 ( 0.0%) 0.0120 ( 5.6%) 0.0101 (
4.7%) Integrity checking
0.0040 ( 2.0%) 0.0000 ( 0.0%) 0.0040 ( 1.8%) 0.0017 (
0.7%) Parsing
0.1920 (100.0%) 0.0200 (100.0%) 0.2120 (100.0%) 0.2143
(100.0%) TOTAL
[~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions -std-compile-opts
Adding test/ofmt.i as a preprocessed C file
Phase: Preprocessing
test/ofmt.i is ignored during this phase
Phase: Translation
compile test/ofmt.i to become an unoptimized LLVM bitcode file
typechecking results:
errors: 0
warnings: 0
Phase: Optimization
optimize ofmt.bc to become an LLVM bitcode file
Phase: Bitcode linking
bclink ofmt.bc to become a file that has been linked
Phase: Bitcode assembly
ofmt.bc is ignored during this phase
Phase: Assembly
ofmt.bc is ignored during this phase
Phase: Linking
ofmt.bc is ignored during this phase
===-------------------------------------------------------------------------==
... Ellsif action timing report ...
===-------------------------------------------------------------------------==
Total Execution Time: 1.3560 seconds (1.4326 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall
Time--- --- Name ---
1.1720 ( 86.6%) 0.0000 ( 0.0%) 1.1720 ( 86.4%) 1.2139 (
84.7%) Optimization
0.1560 ( 11.5%) 0.0040 (100.0%) 0.1600 ( 11.7%) 0.1833 (
12.8%) Type checking
0.0120 ( 0.8%) 0.0000 ( 0.0%) 0.0120 ( 0.8%) 0.0227 (
1.5%) Elaboration
0.0080 ( 0.5%) 0.0000 ( 0.0%) 0.0080 ( 0.5%) 0.0099 (
0.6%) Integrity checking
0.0040 ( 0.2%) 0.0000 ( 0.0%) 0.0040 ( 0.2%) 0.0025 (
0.1%) Parsing
1.3520 (100.0%) 0.0040 (100.0%) 1.3560 (100.0%) 1.4326
(100.0%) TOTAL
[~/elsa/ellsif] dev% wc test/ofmt.i
2899 7781 67913 test/ofmt.i
[~/elsa/ellsif] dev%
Sorry to add noise to the list with this. I'm just very excited. ;-)
Again, my compliments to both the Elsa and LLVM teams. It says a lot
that I got this far in 19 days of part-time work.
-Rich
On 12/21/07, Richard Pennington <rich at pennware.com> wrote:> I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works).Er. Hm. Can you explain the name? The problem with names like "ellsif" is that it sounds like "else if". I like the fact that it reminds one of Elsa.> > [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions -std-compile-optsOk, this indicates that you are developing your compiler in the elsa directory. As I have said before, this is not going to work as Scott wants elsa to be "done". Oink was invented as a bucket to put elsa tools into and that is the best place for it. I suppose you might convince Scott otherwise but I doubt it and for now I am the maintainer.> Adding test/ofmt.i as a preprocessed C file > Phase: Preprocessing > test/ofmt.i is ignored during this phaseWhat preprocessor are you using? Taras has already found one that is working for him and that is licensed under BSD and that has some features in it that he needs for source to source transformation. I would like us to all use the same one.> > Sorry to add noise to the list with this. I'm just very excited. ;-) > Again, my compliments to both the Elsa and LLVM teams. It says a lot > that I got this far in 19 days of part-time work.Excitement is good and I don't mind the email at all. Please however do respond to some of my concerns. Daniel
>> Adding test/ofmt.i as a preprocessed C file >> Phase: Preprocessing >> test/ofmt.i is ignored during this phase >> > > What preprocessor are you using? Taras has already found one that is > working for him and that is licensed under BSD and that has some > features in it that he needs for source to source transformation. I > would like us to all use the same one. >I'd like to clarify my intentions here. I designed the preprocessor integration in such a way that it doesn't depend on the specific preprocessor too much. MCPP is nice in that it's BSD, but it's rather slow, so no need to require people to use it. Users can implement the undo-log preprocessor using libcpp or maybe yank it out of clang which is also BSD. Taras
Daniel Wilkerson wrote:> On 12/21/07, Richard Pennington <rich at pennware.com> wrote: >> I'm a little further along now. I've started to put together a simple >> driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think >> it works). > > Er. Hm. Can you explain the name? The problem with names like > "ellsif" is that it sounds like "else if". I like the fact that it > reminds one of Elsa.It does sound like "elsif". By design. I wanted to remind people of Elsa and also of LLVM, hence the "ll". Maybe you could read it as something like "if gcc else if ellsif". ;-)> >> [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions -std-compile-opts > > Ok, this indicates that you are developing your compiler in the elsa > directory. As I have said before, this is not going to work as Scott > wants elsa to be "done". Oink was invented as a bucket to put elsa > tools into and that is the best place for it. I suppose you might > convince Scott otherwise but I doubt it and for now I am the > maintainer.I'm in elsa/ellsif. elsa is in elsa/elsa. I build elsa into a library and link it into ellsif. (Just like else does smbase, etc.) I'm not sure what "done" means. I've had to touch a lot of areas in Elsa to make this work. I've had to modify the type checker a bit to get standard conversions in places that didn't have them. I added a loc field to expression nodes for debug information and error reporting. etc. etc. It isn't quite done for my purposes. Sorry if I've broken any rules, but I just found Elsa a month ago and wasn't following its development or the mailing list before that.> >> Adding test/ofmt.i as a preprocessed C file >> Phase: Preprocessing >> test/ofmt.i is ignored during this phase > > What preprocessor are you using? Taras has already found one that is > working for him and that is licensed under BSD and that has some > features in it that he needs for source to source transformation. I > would like us to all use the same one.I'm using the gcc as a preprocessor for now. I plan to drop a preprocessor that I wrote a while ago in sometime next week, if the holidays don't get in the way. ;-)> >> Sorry to add noise to the list with this. I'm just very excited. ;-) >> Again, my compliments to both the Elsa and LLVM teams. It says a lot >> that I got this far in 19 days of part-time work. > > Excitement is good and I don't mind the email at all. > > Please however do respond to some of my concerns.I hope I've given some clarification. By the way, this code is owned by me. I'm not doing on my employer's time or using their resources. -Rich
On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote:> I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works). > > The file being compiled is a "printf" function. Here are timing > results > for optimized and unoptimized runs:Cool, this is very nice!> Sorry to add noise to the list with this. I'm just very excited. ;-) > Again, my compliments to both the Elsa and LLVM teams. It says a lot > that I got this far in 19 days of part-time work.This is a very cool hack, but I'm curious: what is your goal with this work? Are you just trying to see if it can be done, or does elsa provide an advantage over using the g++ parser with llvm? -Chris
Chris Lattner wrote:> On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > >> I'm a little further along now. I've started to put together a simple >> driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think >> it works). >> >> The file being compiled is a "printf" function. Here are timing >> results >> for optimized and unoptimized runs: > > Cool, this is very nice! > >> Sorry to add noise to the list with this. I'm just very excited. ;-) >> Again, my compliments to both the Elsa and LLVM teams. It says a lot >> that I got this far in 19 days of part-time work. > > This is a very cool hack, but I'm curious: what is your goal with this > work? Are you just trying to see if it can be done, or does elsa > provide an advantage over using the g++ parser with llvm? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >Well, primarily I'm doing it for fun. My background is in compiler design and embedded systems programming, so I'm interested in both the front end and back end aspects. I've build gcc many times over the years for different target processors and was never able to get my head around it internally. It is incredibly complex. I also didn't like the fact that I had to have N copies of gcc to support N processors. I became interested in Elsa (via google) because I liked its extensible nature. I can drop in new syntax rules easily. It was also fairly easy to understand. At first I looked into SUIF and started down that path. I wasn't entirely pleased with the results. Then I realized SUIF had been dead for about 5 years so I started looking around for alternatives and stumbled on LLVM. It was easy to lower the Elsa AST to LLVM by using Elsa's extension capability. I'm now at the point where I can see that compiling C with Elsa is a done deal. I have about 90% (or more) of basic C covered. I decided that I wanted a cleaner way to move forward so I started writing the ellsif driver to automate the steps and make Elsa->LLVM look like a real tool. Does Elsa provide an advantage over g++? For me, understanding it is a big plus. ;-) In addition, Elsa has a Berkeley-like license which I prefer. I'll let you know if Elsa is a good choice after I get a little further along adding the C++ support. Since I only have a few weeks invested in this project, I won't feel too bad if Elsa turns out to be a dead end. Along the way I found LLVM, which is definitely the way to go. I'd like to get the Elsa stuff behind me because I'm itching to do an LLVM code generator for the Altera Nios2. ;-) I started by copying the MIPS sources and am studying them to get a feel for what's required. -Rich