SourceForge.net LogoThe Eiffel Compiler / Interpreter (tecomp)

doc/tecomp/roadmap

Roadmap

The following reflects the current thinking on the possible evolution of tecomp. Any suggestions comments are welcome (just post/discuss on the tecomp mailing list).

Version 1.0

Version 1.0 will accept the full standard Eiffel language (ECMA).

Tecomp will parse the source code, validate it and execute the code in its virtual machine. Compilation to C or native code will not be part of version 1.0

Compilation to native

In order to get native code, the following options are considered:

  1. Compile to C and then C to native.
  2. Integration of tecomp as language front end into gcc.
  3. Integration of tecomp as a frontend to the low level virtual machine.

The first option is highly desirable because it is the most straighforward way and also the way most other Eiffel compilers (SmartEiffel, ISE Eiffel, Gobo Eiffel) have chosen. This is the classic way to compile Eiffel to native code.

The second option is interesting, because it could help to make Eiffel more popular. Gcc is the C/C++ compiler available for Unix/Linux systems. Nearly all Unix/Linux systems have gcc installed or have a very comfortable way to get gcc installed via prepared packages from the distributor.

Some investigation on the possibility to integrate tecomp into gcc have already been done. No blocking point have been encountered. Gcc has already been prepared by its authors to integrate different language front ends (e.g. Ada).

The third option (integration into LLVM) is possible as well. Since LLVM has a builtin just-in-time compiler the option has a big plus. However, LLVM has not (yet?) gained a lot of popularity.

It has not yet been decided which option to go. It could be either option 1 only, or option 1 and 2 or option 1 and 3. Any suggestions are welcome.

Standard libraries

A set of standard libraries have to be provided which allow POSIX system calls, i.e. to equip Eiffel with an interface to make system calls (sockets, raw file access, create/delete files, buffered/unbuffered io, etc.).

Further evolution

Full language compliance and compilation to native are mandatory. There are already some ideas for the further evolution of tecomp.

Improved garbage collection for real time systems

Developers of real time systems often shy away from garbage collection because of the unpredictable behaviour of garbage collection. In order to make Eiffel attractive for embedded real time systems garbage collection has to be improved.

There is a concept for producing garbage free SW with Eiffel. Due to its property to be strongly typed, the compiler could analyze the potential linking of objects at compile time and determine the earliest point to reclaim an object. This would be equivalent to C or C++ code, where the developer frees memory as soon as it can no longer be referenced.

The tecomp compiler could be improved to be able to analyze such situations at compile time and indicate to the developer, if the analysis has been completely sucessful or if there are still some remaining objects which need to be managed by a garbage collector at runtime.

It can be expected that a lot of common patterns can be recognized and that it is possible to write Eiffel programs which do not have any garbage collection overhead.

Concurrency

SCOOP (simple concurrent object oriented programming) is an interesting concept to implement concurrency in Eiffel.

Assertion verification

One of the most powerful features of Eiffel is its design by contract via pre- and postconditions, class invariants, loop variants and invariants and check instructions.

The assertions support the writing of high quality software. Furthermore they help to detect bugs close to the origin and therefore reduce debugging time significantly.

Tecomp could be improved to be able to verify part of the assertions at compile time and indicate to the developer the verified assertions.

This goal is highly ambitious, if done on all assertions (i.e. complete verification). If the goal is made more practical (i.e. verification of the most common assertions) the goal might come into reach.

 Local Variables: 
 mode: outline
 coding: iso-latin-1
 outline-regexp: "=\\(=\\)*"
 End:
Table of contents

- Version 1.0

- Compilation to native

- Standard libraries

- Further evolution

- Improved garbage collection for real time systems

- Concurrency

- Assertion verification


ip-location