%\section{Introduction}
\LOTOS\ \cite{iso8807} is a very complicated language
both syntactically and semantically.
Generation of executable code out of a \LOTOS\ specification is a task
that must be tackled in several stages to keep complexity under control.

\LOTOS\ is composed of two clearly distinguishable parts:
data and behaviour.
The data part is pretty complex due to the overloading and structuring
facilities,
and scope (or visibility) laws.
%These conditions make a serious business of compiling the data part.
In this paper it is assumed that some kind of {\em library} exists
that provides the functions to perform operations on data types,
to evaluate values and predicates,
and most notably there is available a function to check for equality
of value expressions according to initial semantics.

For the behaviour part,
a clear operational semantics is provided in \cite{iso8807}.
It may be directly implemented by means of a set of rewrite rules
working on some abstract syntax representation.
This approach is followed, for instance,
in simulators \cite{logrippo:swpe,sedos:simulator},
but its efficiency is not satisfactory for a compiler.
\LOTOS\ is able to specify highly concurrent systems,
where very many activities may be involved at any moment:
the exact control threads that exist at each stage of execution,
as well at their interrelationship,
are only known at run-time.

In this framework,
code generation is an enormous task,
and plenty of implementation decisions have to be taken
to move from very high level \LOTOS\ 
to very low level machine code.
Furthermore,
as experience is gained on the understanding of the language,
and implementation issues,
these decisions may be subject to severe changes.
In order to keep complexity under control,
and permit easy maintenance,
it is of paramount importance to identify intermediate stages,
and keep them clearly isolated.
If this isolation is achieved,
each one of the stages may be kept under control,
and may be easily replaced without disturbing the others.

In \TOPO\ \cite{topo:l2c}
(a \LOTOS\ compiler)
two such intermediate stages are identified and used.
First stage is the \LBM\ presented below,
where the syntactic and semantic complexity of \LOTOS\ has been
resolved by the semantics analyzer,
and an abstract model to implement \LOTOS\ has been chosen.
Still it is open to several concrete implementations.
\LBM\ stands for \LOTOS\ Behaviour Machine.

The second stage is a systems programming language.
Currently,
\TOPO\ is able to produce either the widely available {\tt C} language,
or the promising {\tt Ada}.
Some hints about the final implementation decisions
taken in \TOPO\ with respect to
deriving {\tt C} code are shown below.\\[-4ex]

\begin{center}
\small
\begin{picture}(0,70)
%\begin{picture}(0,40)
\unitlength 0.6mm
  \put(  0,60){\makebox(0,0){LOTOS}}
  \put(-15,37){\makebox(30,6){\bf\LBM}}
  \put(-20,20){\makebox(0,0){Ada}}
  \put(  0,20){\makebox(0,0){{\tt C}}}
  \put( 20,20){\makebox(0,0)[l]{prog. lang.}}
  \put(-20, 0){\makebox(0,0)[r]{HP-9000}}
  \put(  0, 0){\makebox(0,0){Sun-4}}
  \put( 20, 0){\makebox(0,0)[l]{target machine}}

  \put(  0, 57){\vector(0,-1){14}}
  \put(  0, 37){\vector(0,-1){14}}
  \put(  0, 17){\vector(0,-1){14}}
  \put( -3, 37){\vector(-1,-1){14}}
  \put( -3, 17){\vector(-1,-1){14}}
  \put(  3, 37){\vector(1,-1){14}}
  \put(  3, 17){\vector(1,-1){14}}
\end{picture}
\end{center}

Some naive points of view
are frequently found when speaking about \LOTOS\ implementations.
It is far too easy to identify \LOTOS\ processes and Operating System
processes,
and make a one to one mapping.
That would be nice, but may be completely unrealistic,
and it must be clear that the \LBM\ presented in this paper
leaves that path open to future considerations.
There are two basic considerations to take into account:
\begin{itemize}
\item
  Tail recursive process instantiation just models conventional loops
  ({\em for, while, until, \ldots}).
  They might be implemented as real processes, 
  but the overhead is too high to be worth.
  Actual experience shows that process instantiation most often falls
  into this category.
\item
  There is ``real'' parallelism in \LOTOS\ expressions built out of the
  {\em parallel} operators.
  These parallel threads of control do not necessarily
  get a name in the user's specification,
  that is, there is not necessarily a {\tt process} for each branch.
  A single name,
  a \LOTOS\ {\tt process},
  may well be behaving as a couple of unnamed actual
  processes at run-time,
  after ``splitting'' around some parallel operator.
\end{itemize}

\LBM\ carefully avoids taking any compromising decision on this
critical issue of mapping to real machine processes.
Concurrent threads of control exist,
but its mapping is delayed to the code derivation stages.
Notice,
that this decision is sometimes not possible at all.
For instance,
if the target machine is to run under a mono-process O.S.
(e.g. under MS--DOS),
there are few opportunities to pass concurrency control to the O.S.

