XEC - the eXperimental Estelle Compiler

Frequently Asked Questions

General

What is XEC?

XEC is an acronym for "eXperperimental Estelle Compiler" It is a tool to create executable implementations from specifications written in the language Estelle. These implementations can run stand-alone, or as part of a larger (automatically or manually created) context.
The XEC toolkit currently consists of the following components:

PET: "Portable Estelle Translator", translates Estelle specifications into an equivalent binary representation.

XEC: "eXperimental Estelle Compiler", translates PET's binary represenation of an Estelle specification into object oriented C++ code.

XEC run-time library: an object oriented C++ library used as runtime library for code generated by XEC.

PATO: "Performance Analysing Tool", a software monitoring tool for performance analysis of XEC-generated Estelle implementations. It consists of a run-time library and a MOTIF based graphical evaluation tool.

EGD: "Estelle Graphical Debugger", a portable JAVA based frontend for the visualization and control of XEC-generated Estelle implementations.

PETRESTORE: a tool that translates PET's binary represenations of Estelle specifications back to text-form.

PETFUSE: a tool for the support of Open Estelle. It fuses a set of open systems and importing environments into a single Standard Estelle Specification.

XEC was created as a platform for implementation and optimization experiments with Estelle. Therefore the generated code is run time efficient, allows static and dynamic optimizations and supports software monitoring and performace analysis.

What is the language supported by XEC?

XEC supports the complete Estelle language defined in [ISO97], except the following restrictions:

The range of INTEGER and of subrange-types is limited to the domain of the C-type "int" of the implementation platform (e.g. [-2,147,483,648 ... 2,147,483,647] on common 32-bit processors). This restriction also applies to integer constants.
WARNING: A run-time overflow of these types will generally not be detected and its result is undefined.

The type INTEGER is not a valid array index type
(e.g. in "ARRAY[INTEGER] OF CHAR")

Functional and procedural parameters (i.e. functions or procedures as parameters to other functions or procedures) are currently being redesigned. Specifications with these language means will not be accepted by the current version of XEC (1.2.1).

The implementation of (unlimited) sets has not yet been tested sufficiently. They may or may not work correctly in the current version of XEC (1.2.1).
(The latter two restrictions will be removed in near future.)
Furthermore, the following extensions to the Estelle language defined in [ISO97] are implemented by XEC:

channel definition with only one single role
(e.g. "CHANNEL duplex (user)")

pseudo comments for

inline C- or C++-code in statement blocks
inline definition of PRIMITIVE and EXTERNAL functions
PATO monitoring options

Translation of Open Estelle Specifications, including the completely independent compilation of open systems and importing environments.

the automatic testing of assert-functions [The95]

transmission of heap-objects "by reference" as interaction parameters
Some of these extensions (e.g. Open Estelle) will require our enhanced version 2.0 of PET (included in the XEC toolkit).

On which (hardware/software) platforms will XEC work?

The compiler XEC (as well as its frontend PET) will work on any platform with a C++-Compiler supporting ANSI/ISO-C++ (according to X3J16/96-0225, WG21/N1043, final draft, December 2, 1996).
On UNIX platforms GNU g++ 2.7 and 2.8 come very close to this requirement, although both have several severe bugs, but in most cases it will work. Perhaps you will need a new linker (from the GNU "binutils" package) to be able to compile XEC.
The generated code and most of the runtime-library can be compiled under the same conditions as XEC itself. All platform dependent elements (e.g. "gettime...()" funtion-calls) are collected in the library source file "xecrt_context.cxx". Porting to non-UNIX platforms (and even to some UNIX platforms) may require some adaptions in this module. Currently XEC and the generated code have been ported to and tested under

Sun SPARC Solaris 2.5 with gcc 2.7.2 and 2.8.1
x86-Linux (Kernel 2.0.33, libc 5.4.44) with gcc 2.7.2
DEC Alpha OSF/1 V3.2 with gcc 2.7.2
QNX 4.22 with WATCOM C 10.5
Ports to the following platforms will (or may) be developed in near future:

Windows'95/98 (probably)
MS-DOS (with DOS-Extender) (probably)
Windows NT 4.0 (x86) (surely)
OS/2 Warp 4.0 (perhaps)
EGD will work on any platform with a JAVA VM supporting JAVA 1.1 and JAVA SWING or JAVA 1.2.
PATO (at least the graphical backend) uses MOTIF (i.e. AFAIK only X11/UNIX).

How do I use XEC?

There are basically 3 steps from a specification to an implementation:

The Estelle specification (x.stl) is translated by the separate compiler frontend PET into an equivalent binary representation (x.obj).

XEC translates this binary representation into object oriented C++ code (x.cxx and x.hxx) and a "make"-file (x.mak).

Under control of the "make"-file a common C++ compiler (e.g. g++) can translate the generated C++ code and the XEC run-time library into an executable file (x).

How do I use the generated implementations?

...

What's the difference between XEC and other Estelle compilers?

Currently there are 3 other Estelle compilers:

EC: the "Estelle Compiler" (EC) is part of the "Estelle Development Toolset" (EDT). It translates Estelle specifications into C code. EDT also includes other tools, e.g. an interactive debugger (EDB).
EDT is a commercial tool-set, sources of the compiler and the run-time library are not broadly available. The generated code is relatively efficient, but hard to understand, especially without the sources of the run-time library.

PET/DINGO: ...
UHH Estelle Compiler: ...

(.........)

Research-Activities Estelle XEC XEC-FAQ

thees@informatik.uni-kl.de
09/04/98