The Eiffel Compiler tecomp 0.2 released

The Eiffel Compiler tecomp 0.2 has been released. It is an open source
compiler currently in development. It is committed to implement
standard Eiffel (ECMA). Acceptance of the full Eiffel language is
expected by the end of 2008.

In its current version it compiles to an internal format and executes
the code. So in its simplest configuration it looks like an
interpreter.

It works on Unix and Windows systems.

Links:
http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

helmut.brandl@gmx.net a écrit :
> The Eiffel Compiler tecomp 0.2 has been released. It is an open source
> compiler currently in development. It is committed to implement
> standard Eiffel (ECMA). Acceptance of the full Eiffel language is
> expected by the end of 2008.
>
> In its current version it compiles to an internal format and executes
> the code. So in its simplest configuration it looks like an
> interpreter.

Would be nice to target this compiler to GCC. Not easy but that will
make Eiffel more visible.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

On 25 Jul., 03:07, Pascal Obry <pas...@obry.net> wrote:

> > In its current version it compiles to an internal format and executes
> > the code. So in its simplest configuration it looks like an
> > interpreter.
>
> Would be nice to target this compiler to GCC. Not easy but that will
> make Eiffel more visible.

Please not at least not as a default. LLVM is the way to go. GCC is so
terrible
slow and for Eiffel total unuseable unless the compiler generates a
good
incremental strategy which nobody currently does.

scholz.lothar@gmail.com a écrit :
> Please not at least not as a default. LLVM is the way to go.

That's indeed another option.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

On Jul 26, 5:52 am, scholz.lot...@gmail.com wrote:
> On 25 Jul., 03:07, Pascal Obry <pas...@obry.net> wrote:
>
> > > In its current version it compiles to an internal format and executes
> > > the code. So in its simplest configuration it looks like an
> > > interpreter.
>
> > Would be nice to target this compiler to GCC. Not easy but that will
> > make Eiffel more visible.
>
> Please not at least not as a default. LLVM is the way to go. GCC is so
> terrible
> slow and for Eiffel total unuseable unless the compiler generates a
> good
> incremental strategy which nobody currently does.

Hello Lothar,

do you have any experience with llvm?

I have looked into gcc (i.e. using tecomp as a language front end for
the gcc) and it seems to be doable. Since gcc is a very stable
project, the option is quite viable.

I have looked into llvm as well. The strategy of the project is very
convincing at first sight. However I don't know how reliable and
stable the llvm is.

Since I have not yet decided how to make compilation to native code
with tecomp I am still open to any proposal.

Regards
Helmut (helmut_brandl@users.sourceforge.net)

The Eiffel Compiler http://www.sourceforge.net/projects/tecomp

On 12 Aug., 05:16, helmut.luis.bra...@gmail.com wrote:

> do you have any experience with llvm?

Well i read the page, the manual and the examples.
Installing the system didn't work for me. Neither 2.2 nor 2.3
worked out of the box on my WinXP 64/MSVC 8.0 system.

And i didn't spend time into resolving the problem.

But of course you can use gcc. The main problem with eiffels
full system analysis and compiling to C strategy is not solved
by gcc nor by llvm. You have a huge c file and need to recompile
just a few methods which may be in multiple files. So you always
recompile a lot of code which did not really change.

My idea to solve this is to write my own prelinker. Using gcc
for the compile to c step and then keeping the object file in
memory (remember i'm writing an eiffel compile server, going
away from the typical command line idea) and then just merge
and replace individual methods in this object file. At the end
the compile server is calling the gnu linker to create the
final executable.

My ideas of an ideal eiffel system are different.
The most important feature for me is to get a
edit-compile-run of less then one second. Good C
output is second.

My semantic analysis phase already scales almost
perfect on a quad core and analysis of
350.000 LOC does only take around a few milliseconds
when the system is hot (after the first compile).

Unfortunately i don't have more time this year and so
backend compilation have to wait until mid 2009.

On Aug 16, 5:39 pm, scholz.lot...@gmail.com wrote:
> But of course you can use gcc. The main problem with eiffels
> full system analysis and compiling to C strategy is not solved
> by gcc nor by llvm. You have a huge c file and need to recompile
> just a few methods which may be in multiple files. So you always
> recompile a lot of code which did not really change.
>
> My idea to solve this is to write my own prelinker. Using gcc
> for the compile to c step and then keeping the object file in
> memory (remember i'm writing an eiffel compile server, going
> away from the typical command line idea) and then just merge
> and replace individual methods in this object file. At the end
> the compile server is calling the gnu linker to create the
> final executable.

The main question for me is: What is the most appropriate granularity
for doing C to native compilation? The feature, the class, the type,
the cluster or ...?

The best incremental strategy can be reached if you use the feature as
its finest granularity. So if you change a feature, you need to
recompile only the used features which depend on that feature. Ideally
only one feature. The price: you need a good incremental linker which
allows you to change individual symbols (which is no problem with the
gnu tools) and you have to manage fine granular representations of
individual features (files or structures in memory for a compile-
server).

The more coarse your granularity is, the more you have to recompile
from C to native.

The next question is: How optimal do you want the C code to be. If you
optimize to C code to the fullest (static call, where possible, etc.)
small changes in the Eiffel source code can cause a lot of
recompilation. Therefore during development, when edit-compile-run
turnaround is crucial, this is not a good idea.

I am trying to find an incremental method for "The Eiffel
Compiler" (tecomp), which gives very fast edit-compile-run performance
(even for the first compile) with reasonable runtime performance
during development and excellent runtime performance with longer
compile cycle for production code.

In order to reach the first goal it is questionable, if compilation to
C is a good option. It might turn out that a compilation via C to
native with a good edit-compile-run turnaround don't give you a better
runtime performance than executing the Eiffel code in the tecomp
virtual machine without going via C to native. For the edit-compile-
run performance, the virtual machine approach is superior (my
experience: Eiffel to IR compilation with validation and global
analysis is tremendously fast compared to C to native compilation)

If the tecomp virtual machine code execution turns out to be too slow
(benchmarks have not yet been done, but the performance seems to be
comparable to JVM execution without JIT), a possible improvement is to
link tecomp to llvm (therefore I am interested in experience) and
produce llvm bytecode. Llvm has very sophisticated tools to link llvm
bytecode. Llvm can execute its bytecode with a JIT, which should give
good runtime performance without the penalty of going via C to native.

Let me try to illustrate the ideas for tecomp:


a) interpreter mode:

tecomp: Eiffel -> execution (interpreter mode)


b) compilation to Eiffel IR (internal representation)

tecomp: Eiffel -> Eiffel IR (with good incrementality)

tecomp: Eiffel IR -> execution (within tecomp's virtual machine)


c) compilation to llvm bc (bytecode)

tecomp+llvm: Eiffel -> llvm bc (with good incrementality)

llvm-jit (lli): llvm bc -> execution (with good runtime performance)



d) compilation to C (the classic approach with a development and a
production mode)

tecomp: Eiffel -> C (granularity?)

gcc: C -> executable


Currently only (a) is working and (b) will be working soon. The user
feedback will help to set the priorities and decide on the options (c)
and/or (d) to implement.

I have implemented the interpreter mode of tecomp as the first option,
because it makes the use of tecomp very easy and the approach is
different from the current existing Eiffel compilers. So it might help
to increase the Eiffel community with an Eiffel compiler which let you
do things which cannot be done with the other ones (e.g. use it like
perl, python or PHP but with full OO power). JITing with llvm might be
something interesting as well .....


Helmut