Eiffel interpreter available
Helmut
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...@users.sourceforge.net
The Eiffel Compiler http://www.sourceforge.net/projects/tecomp
Documentation http://tecomp.sourceforge.net
scholz...@gmail.com
> 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.
peter_...@hotmail.com
> The hardest thing was the template system ...
What do you mean by the "template system", Lothar? Do you mean
generics?
-- Peter
scholz...@gmail.com
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.
Helmut
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
scholz...@gmail.com
> 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.
Helmut
> 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/listinfo/tecomp-user
Ulrich Windl
> 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... ;-)
Helmut
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/listinfo/tecomp-user