Eiffel interpreter available

Most of Eiffel compilers act like usual compilers. They compile to C
and then to native or directly to native machine code.

The Eiffel Compiler tecomp has chosen a different strategy. It its
simplest configuration it works like an interpreter. Just feed the
Eiffel source code and you get it executed immediately (see
http://www.sourceforge.net/projects/tecomp to download and
http://tecomp.sourceforge.net for documentation).

Compilation to C or native code is seen as an optimization step.

Tecomp does not yet accept the full ECMA Eiffel language. But it
accepts already a considerable subset of the Eiffel language. Full
compliance will be reached by the end of 2008.

For compilation to native code integration into gcc is considered.
Another viable option is to use the low level virtual machine in order
to get a JIT (just in time) compiler for various platforms.

Regards
Helmut
mailto: helmut.brandl@users.sourceforge.net
The Eiffel Compiler http://www.sourceforge.net/projects/tecomp
Documentation http://tecomp.sourceforge.net

On 12 Aug., 06:14, Helmut <helmut.bra...@gmx.net> wrote:
> Most of Eiffel compilers act like usual compilers. They compile to C
> and then to native or directly to native machine code.

A little hint from me after writting my own eiffel compiler (not
finished).
The hardest thing was the template system, you should focus on this
first.
Object Orientation, even multiple inheritence is much easier to
implement.
In both phases: semantik validation and code generation.

Once you have done this i will give it a try.

On Aug 12, 10:21*pm, scholz.lot...@gmail.com wrote:
> The hardest thing was the template system ...

What do you mean by the "template system", Lothar? Do you mean
generics?

-- Peter

On 13 Aug., 18:08, peter_gum...@hotmail.com wrote:
> On Aug 12, 10:21 pm, scholz.lot...@gmail.com wrote:
>
> > The hardest thing was the template system ...
>
> What do you mean by the "template system", Lothar? Do you mean
> generics?
>
> -- Peter

Yes. Maybe i used a wrong algorithm but it is still the only thing
not working well for my system. If you don't want to use excessive
O(n*n) memory like gobos gec (which already make people think about
using a 64bit system) then you need a clever algorithm which is not
simply duplicating complete ASTs.

On Aug 13, 7:52 am, scholz.lot...@gmail.com wrote:
> On 13 Aug., 18:08, peter_gum...@hotmail.com wrote:
>
> > On Aug 12, 10:21 pm, scholz.lot...@gmail.com wrote:
>
> > > The hardest thing was the template system ...
>
> > What do you mean by the "template system", Lothar? Do you mean
> > generics?
>
> > -- Peter
>
> Yes. Maybe i used a wrong algorithm but it is still the only thing
> not working well for my system. If you don't want to use excessive
> O(n*n) memory like gobos gec (which already make people think about
> using a 64bit system) then you need a clever algorithm which is not
> simply duplicating complete ASTs.

Hello Lothar,

I don't have the problem you mentioned. Tecomp only has one internal
representation per class. For each type I have some lean additional
information (e.g. describing layout information for the actual
generics). Also the routines have just some lean additional
information related to the actual generics. With that the virtual
machine executes well. It should have performance e.g. to executing
java code without JITing. I hope to get a JIT for tecomp, if I combine
it with llvm.

For native compilation clearly you have to make some space time
tradeoffs. The fastest executing code will have specific compiled
functions for each type. But this is necessary only for used routines.
This can lead to the same "code bloat" already obeserved in C++.
Without optimization for maximum speed, a more compact compiled C code
is possible.

Could you explain the difficulties you encountered a little bit more.
Maybe I overlooked something. Why do you duplicate the ASTs (I assume
the ASTs are your internal representation of the Eiffel source code)?

Regards
Helmut

On 14 Aug., 19:44, Helmut <helmut.bra...@gmx.net> wrote:

> I don't have the problem you mentioned.

Yes, as i said maybe i did it wrong. There are multiple
ways you can do it. The easiest is just to duplicate AST
(abstract syntax tree) and then you don't need any special
code for generics. It works fine but as i said it does use
a lot of memory.

If you the substitution on demand and just have to check
the generic classes once you need a little more complex
algorithm.

> For native compilation clearly you have to make some space time
> tradeoffs. The fastest executing code will have specific compiled
> functions for each type. But this is necessary only for used routines.

Well and here it comes, when do you find the dead code?
Normally this is done in the last steps because otherwise you have a
huge interaction between parse and analyse phase. So the easiest way
is to do the semantik analysis just for all methods, then flag which
methods are alive and generate code for it.

As i said, the code generator seems to be extremely simple without
generics. You just have to take care if the data layout of a class
has
changed and in this case generate again all methods that access
variable
members. Thats the benefit of having multiple inheritance and
whole system analysis.

On Aug 16, 5:53 pm, scholz.lot...@gmail.com wrote:
> On 14 Aug., 19:44, Helmut <helmut.bra...@gmx.net> wrote:
> > For native compilation clearly you have to make some space time
> > tradeoffs. The fastest executing code will have specific compiled
> > functions for each type. But this is necessary only for used routines.
>
> Well and here it comes, when do you find the dead code?
> Normally this is done in the last steps because otherwise you have a
> huge interaction between parse and analyse phase. So the easiest way
> is to do the semantik analysis just for all methods, then flag which
> methods are alive and generate code for it.
>

Not necessarily. I can firstly parse the whole system (i.e. convert
the Eiffel source code to some internal representation), then start at
the root procedure and validate (i.e. semantic analysis) only used
features. Thats a kind of "lazy mode". I.e. you do not touch "dead
code". As far as I know, SmartEiffel works in that manner.

For tecomp currently all features are validated (used and unused). But
thats just done that way because it is the simplest algorithm (as you
said). I intend to switch to the lazy mode as default for fast edit-
compile-run turnaround and enable full validation (important for
libraries) on request.

Regards
Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net
Mailing list: https://lists.sourceforge.net/lists/...fo/tecomp-user

Helmut <helmut.brandl@gmx.net> writes:

> Most of Eiffel compilers act like usual compilers. They compile to C
> and then to native or directly to native machine code.
>
> The Eiffel Compiler tecomp has chosen a different strategy. It its
> simplest configuration it works like an interpreter. Just feed the
> Eiffel source code and you get it executed immediately (see

Can you elaborate on "immediately"?: You mean once the system has been
compiled into some intermediate code. I doubt you can run Eiffel code like
BASIC... ;-)


> http://www.sourceforge.net/projects/tecomp to download and
> http://tecomp.sourceforge.net for documentation).
>
> Compilation to C or native code is seen as an optimization step.
>
> Tecomp does not yet accept the full ECMA Eiffel language. But it
> accepts already a considerable subset of the Eiffel language. Full
> compliance will be reached by the end of 2008.
>
> For compilation to native code integration into gcc is considered.
> Another viable option is to use the low level virtual machine in order
> to get a JIT (just in time) compiler for various platforms.
>
> Regards
> Helmut
> mailto: helmut.brandl@users.sourceforge.net
> The Eiffel Compiler http://www.sourceforge.net/projects/tecomp
> Documentation http://tecomp.sourceforge.net

On Aug 18, 6:38 am, Ulrich Windl <Ulrich.Wi...@RZ.Uni-Regensburg.DE>
wrote:
> Helmut <helmut.bra...@gmx.net> writes:
> > Most of Eiffel compilers act like usual compilers. They compile to C
> > and then to native or directly to native machine code.
>
> > The Eiffel Compiler tecomp has chosen a different strategy. It its
> > simplest configuration it works like an interpreter. Just feed the
> > Eiffel source code and you get it executed immediately (see
>
> Can you elaborate on "immediately"?: You mean once the system has been
> compiled into some intermediate code. I doubt you can run Eiffel code like
> BASIC... ;-)

clearly not like BASIC. Under the hood it is compilation. Tecomp has a
parser which converts the Eiffel code into some intermediate
representation (a more compact form than ASTs) and then a validator,
which validates the code. So if you write big programs in Eiffel, you
will notice the time needed for parsing and validation. But for small
programs and medium sized programs you have the impression of
immediate execution. Try it! It is like PHP, Perl or other scripting
languages.

But tecomp will soon get the possibility to store the compiled
program. That is indispensable for large programs.

Regards
Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net
Mailing list: https://lists.sourceforge.net/lists/...fo/tecomp-user